UDP sendto() returning ENOBUFS - "No buffer space available"

[Adrian Chadd]

Hi,


On 18 July 2014 13:40, Bruce Evans <brde at optusnet.com.au> wrote:
> On Fri, 18 Jul 2014, hiren panchasara wrote:
>
>> On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>>>
>>> Hi!
>>>
>>> So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
>>> udp_output() -> ip_output()
>>>
>>> udp_output() does do a M_PREPEND() which can return ENOBUFS. ip_output
>>> can also return ENOBUFS.
>>>
>>> it doesn't look like the socket code (eg sosend_dgram()) is doing any
>>> buffering - it's just copying the frame and stuffing it up to the
>>> driver. No queuing involved before the NIC.
>>
>>
>> Right. Thanks for confirming.
>
>
> Most buffering should be in ifq above the NIC.  For UDP, I think
> udp_output() puts buffers on the ifq and calls the driver for every
> one, but the driver shouldn't do anything for most calls.  The
> driver can't possibly do anything if its ring buffer is full, and
> shouldn't do anything if it is nearly full.  Buffers accumulate in
> the ifq until the driver gets around to them or the queue fills up.
> Most ENOBUFS errors are for when it fills up.  It can very easily
> fill up, especially since it is too small in most configurations.
> Just loop calling sendto().  This will fill the ifq almost
> instantly unless the hardware is faster than the software.

For if_transmit() drivers, there's no ifp queue. The queuing is being
done in the driver.

For drivers with if_transmit(), they may end up doing direct DMA ring
dispatch or they may have a buf_ring in front of it.There's no ifq
anymore. It upsets the ALTQ people too.



-a