On Monday, September 17, 2012 1:45:12 pm Adrian Chadd wrote: > On 17 September 2012 10:16, John Baldwin <[email protected]> wrote: > > > 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). > > I'm still not convinced that going the if_start route (with > process-to-completion) is going to work well when forwarding gobs of > packets on anything bar ${BIG_IRON}, but that aside..
Eh? For virtual interfaces, if_transmit introduces less overhead than using if_start (no locking, queueing, dequeueing, etc.). I expect that to be a net win for smaller boards. > It may be nice to introduce a virtual TX completion callback? Ie, a > child driver could signal that it's successfully drained its TX queue, > notifying any parent drivers that they can send more? That could work, but I generally think if_transmit is a better route for these sorts of things. That turns these interfaces into simple filters rather than building up their own queue, etc. -- John Baldwin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
