Date: Wed, 18 Dec 2013 15:51:45 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Garrett Wollman <wollman@hergotha.csail.mit.edu> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Removing queue length check in ip_output (was Re: buf_ring in HEAD is racy) Message-ID: <CAJ-VmomzW%2Bmx_zLZ9sgQgvjDqQyH_bbbhd8KnPaOVwx4US1X0Q@mail.gmail.com> In-Reply-To: <201312182240.rBIMeTUE006362@hergotha.csail.mit.edu> References: <CAJ-VmomyPq_2K-MFhb7vt6MM7RBbmn7yaTzUXb7%2BN7TbW1RmHQ@mail.gmail.com> <201312182240.rBIMeTUE006362@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 December 2013 14:40, Garrett Wollman <wollman@hergotha.csail.mit.edu> wrote: > In article > <CAJ-VmomyPq_2K-MFhb7vt6MM7RBbmn7yaTzUXb7+N7TbW1RmHQ@mail.gmail.com>, > adrian@freebsd.org writes: > >>.. it's totally bogus in an if_transmit / SMP world. There's no >>locking and there's no guarantee that there will be headroom in the >>queue between this point and the later call to the if_output() method. > > The theory is that when transmitting fragments, it's desirable to have > all-or-nothing transmit behavior with respect to the original packet. > Transmitting incomplete fragmented packets wastes resources on the > local CPU, in the network, and on the remote system, so you should not > do so when it is possible to avoid it. Right, but this API definitely can't guarantee this as it presently stands anyway. > Ideally, there would be an if_reserve(ifp, N) interface that hands you > a token that you can then pass back N times to if_transmit(). But > it's not clear to me how common or necessary this is, except perhaps > on very busy authoritative DNS servers. (Are there any other > applications for fragmented UDP these days?) So it might not be worth > the effort. Ideally we'd pass a list of fragments to the next layer up and such and said layers would treat that list as a "send all or nothing" unit. I have the same issues in the wifi stack with 802.11 fragments. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomzW%2Bmx_zLZ9sgQgvjDqQyH_bbbhd8KnPaOVwx4US1X0Q>