Changes in the network interface queueing handoff model

[John-Mark Gurney]

Robert Watson wrote this message on Mon, Jul 31, 2006 at 18:08 +0100:
> >I question whether you need a fallback software if_snd queue at all for 
> >modern devices such as the Intel and Broadcom gigabit chips.  The hardware 
> >transmit descriptor rings typically have sizes of the order of 256 
> >descriptors.  I think if the ring fills up, you could simply drop the 
> >packet with ENOBUFS.  That's what happens if the if_snd queue fills up, 
> >and its maximum size is comparable to the sizes of modern descriptor 
> >rings.  It would simplify things quite a bit to eliminate the if_snd queue 
> >entirely for such devices.
> 
> I tend to agree, but implemented full queueing support for if_em to make 
> sure I understood to complexity implications of completely removing 
> queueing from the ifnet side dispatch.  I guess an interesting question for 
> us is how we decide what the right threshold is to implement software 
> queuing.  Do any if_em cards need software queueing, or do they all have 
> adequate in-hardware queues as is?  Entirely cutting the queue code would 
> significantly simplify em_startmbuf.

This work tends to lead to a generic ethernet card framework that I've
been thinking about.. where instead of cards doing all the handling of
a ring buffer, the card registers a few functions to manipulate a ring
buffer (if it has one), and does the necessary work...  Though encoding
all the different style of ring buffers may be interesting, per packet
instead of per segment (if_re)...

The other part is to digest the current monolithic lock structure that
the ethernet cards have, into three (or four) different locks, tx head,
tx tail, rx head & tail...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."