Date: Fri, 18 Jul 2014 11:28:40 -0700 From: hiren panchasara <hiren.panchasara@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: UDP sendto() returning ENOBUFS - "No buffer space available" Message-ID: <CALCpEUE-vebmaGSK5aGM%2B3q5YqzXkn1P=St7R8G_ztmHmgUBBA@mail.gmail.com> In-Reply-To: <CAJ-VmokEiZMpdfNjs%2B-C9pmRcjOOjjNGTvM88muh940sr7SmPw@mail.gmail.com> References: <CALCpEUE7OtbXjVTk2C8%2BV7fjOKutuNq04BTo0SN42YEgX81k-Q@mail.gmail.com> <CAJ-VmokEiZMpdfNjs%2B-C9pmRcjOOjjNGTvM88muh940sr7SmPw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > So a _well behaved_ driver will return ENOBUFS _and_ not queue the > frame. However, it's entirely plausible that the driver isn't well > behaved - the intel drivers screwed up here and there with transmit > queue and failure to queue vs failure to transmit. > > So yeah, try tweaking the tx ring descriptor for the driver your'e > using and see how big a bufring it's allocating. Yes, so I am dealing with Broadcom BCM5706/BCM5708 Gigabit Ethernet, i.e. bce(4). I bumped up tx_pages from 2 (default) to 8 where each page is 255 buffer descriptors. I am seeing quite nice improvement on stable/10 where I can send *more* stuff :-) cheers, Hiren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALCpEUE-vebmaGSK5aGM%2B3q5YqzXkn1P=St7R8G_ztmHmgUBBA>