Date: Fri, 18 Jul 2014 20:34:48 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: hiren panchasara <hiren.panchasara@gmail.com>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: UDP sendto() returning ENOBUFS - "No buffer space available" Message-ID: <CAJ-Vmonunb=WqcyJ%2BhJNDknj%2BzjMQVOWWk%2Bu=MqhXkJkcm_DFQ@mail.gmail.com> In-Reply-To: <20140719053318.I15959@besplex.bde.org> References: <CALCpEUE7OtbXjVTk2C8%2BV7fjOKutuNq04BTo0SN42YEgX81k-Q@mail.gmail.com> <CAJ-VmokEiZMpdfNjs%2B-C9pmRcjOOjjNGTvM88muh940sr7SmPw@mail.gmail.com> <CALCpEUE-vebmaGSK5aGM%2B3q5YqzXkn1P=St7R8G_ztmHmgUBBA@mail.gmail.com> <20140719053318.I15959@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 18 July 2014 13:40, Bruce Evans <brde@optusnet.com.au> wrote: > On Fri, 18 Jul 2014, hiren panchasara wrote: > >> On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd <adrian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmonunb=WqcyJ%2BhJNDknj%2BzjMQVOWWk%2Bu=MqhXkJkcm_DFQ>