Date: Fri, 13 Dec 2013 13:51:18 -0800 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Yong-Hyeon Pyun <pyunyh@gmail.com>, FreeBSD Net <freebsd-net@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Jack F Vogel <jfv@freebsd.org>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c Message-ID: <CAJ-VmokoujrNBO21oOdTuzncamS%2BtAjCUKjt4ywJaySL2rAo6g@mail.gmail.com> In-Reply-To: <201312131326.28952.jhb@freebsd.org> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <CAJ-Vmok9oy5BTU8f2KrRU5NBaxOZWF11qO2Z7=KTrkFhfBc0cQ@mail.gmail.com> <CAJ-VmomNf2m3Qinxz_vN5gXPcMnJmysamR4LPRcK=vPKJvG_DA@mail.gmail.com> <201312131326.28952.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 December 2013 10:26, John Baldwin <jhb@freebsd.org> wrote: > On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote: >> Jack / John - thoughts? > > Note that if_start has always worked the way if_transmit would work with the > err = 0 change. All the other drivers in the tree are already giving you an > error if an earlier packet in the IFQ fails to transmit, and it's been that > way for decades. If you decide to make if_transmit precise (only return an > error if the specific packet fails), the corresponding change for if_start() > drivers would be to never return an error ever. Right. If we want some kind of sane network behaviour moving forward we .. well, we have to define it as being sane. :-) IMHO if_start()'s API should've been: * queue something to the ifnet queue - fail it we can't queue it * call if_start() to start trying to transmit something - a failure is not that the queued frame failed, but the driver is unable to dequeue frames. Anyone using if_start() failing as "the frame i just queued failed to transmit" is broken and well, we should just replace it with if_transmit(). > It's not clear to me what the impact of that would be. However, the current > patch to return 0 in the drbr_putback case would at least restore things to > the previous status quo from the past few decades for both if_start() and > if_transmit() drivers. I believe the most correct return behaviour from if_transmit() is "the frame was successfully queued to the driver; it's now up to the driver to eventually send the frame." If the driver does direct dispatch then it'll error out if it couldn't queue the frame to the hardware TX descriptor ring/queue/blah. If the driver does its own queuing then it's up to the driver itself to fail on the hardware transmit function and then retry it when appropriate. It shouldn't be dropping frames during normal transmit unless there's some kind of policy in place to do so - and yes, this is a separate discussion to have with andre and rrs. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokoujrNBO21oOdTuzncamS%2BtAjCUKjt4ywJaySL2rAo6g>