Date: Mon, 17 Sep 2012 13:16:45 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-net@freebsd.org Cc: Ryan Stone <rysto32@gmail.com> Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? Message-ID: <201209171316.45029.jhb@freebsd.org> In-Reply-To: <CAFMmRNzkwbQpUZ3OOoMKVdrz=dePc5fkeX3m-5vXtiWJ7qXwVA@mail.gmail.com> References: <CAFMmRNzkwbQpUZ3OOoMKVdrz=dePc5fkeX3m-5vXtiWJ7qXwVA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, September 17, 2012 11:49:59 am Ryan Stone wrote: > I know that there have been a lot of discussions about fixing how > packets are handed off to ifnets due to the current methods being > extremely race-prone. Has there been any consensus on how the problem > is going to be solved? > > In my particular case, I've seen an if_bridge interface whose if_snd > queue is full, and once an ifnet reaches that point it will never > transmit anything ever again unless its driver manually calls the > start method somehow. > > As a short-term fix I'm temped to call to if_start in IFQ_HANDOFF_ADJ > even if IFQ_ENQUEUE returns an error, to ensure that the queue will be > drained eventually, but I'm wondering if people are actively working > on longer-term fixes. I think for if_bridge the fix is that it no longer uses if_start. :) For real hardware you will get some sort of TX completion interrupt that will restart the transmit queue. Virtual software-only interfaces such as vlan(4) and if_bridge(4) don't have that luxury though, and the best bet for them is to probably have them use if_transmit instead. vlan(4) and if_bridge(4) are already fixed for that (if_bridge was only fixed a week or so ago in HEAD). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209171316.45029.jhb>