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