Re: Changes in the network interface queueing handoff model

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."
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages