Date: Mon, 24 Dec 2012 19:08:12 -0800 From: Adrian Chadd <adrian@freebsd.org> To: mike@karels.net Cc: freebsd-net <freebsd-net@freebsd.org>, Ryan Stone <rysto32@gmail.com>, Tsaregorodtsev Denis <telemat@extrim.it> Subject: Re: 'no buffer space available' after switch goes down on freeBSD 7.3 Message-ID: <CAJ-VmomK60BJkODzzCOJt9eSaQtZeDgMyfKCjB3wHdXf__X7%2BQ@mail.gmail.com> In-Reply-To: <201212250159.qBP1x63t099398@mail.karels.net> References: <CAJ-Vmo=2kB8TgiHK_xtfAmS4g=Np1-Ebfa1A3HvzUOqpTACBEA@mail.gmail.com> <201212250159.qBP1x63t099398@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 December 2012 17:59, Mike Karels <mike@karels.net> wrote: >> [adrian] >> I think we may need another if_* method which specifically attempts to >> service the TX queue again; versus just waiting for if_transmit() to >> make some progress. > In my opinion, it is wrong of the drivers to queue packets while link > is down. The packets are delayed indefinitely, and are useless at best. > In my company's product (McAfee firewall), we had problems with state-sharing > packets that were way out of date in a cluster. We changed the drivers to > empty the queue and discard subsequent packets when link was down. No > special change is needed to restart: the next time a packet is transmitted > after link comes up, that packet is sent. Our change is not necessarily > done the way I'd do it for FreeBSD, but it minimizes changes. Patch > available on request. I think that's a good way to treat it. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomK60BJkODzzCOJt9eSaQtZeDgMyfKCjB3wHdXf__X7%2BQ>