On Tue, Jul 06, 2004 at 04:10:11AM +0000, Charles M. Hannum wrote:
> So, after fixing the ne2000.c error that was causing devices to lock up, I 
> decided to look at all the other padding changes that were committed at the 
> same time.  What I found is:
> 
> * seeq8005.c pads 4 bytes longer than needed.
> * rtl81x9.c and if_vr.c force a copy of every packet that's padded.
> * if_el.c, mx98905.c and ne2000.c use inefficient output methods during 
> padding.
> 
> It also seems poor that this is done in a gazillion places and a gazillion 
> different ways.
> 
> I think, given current numbers, that in ~all cases, a small enough packet to 
> require padding always fits with a single mbuf, and in this case it is always 
> most efficient to just pad it with 0s in core before sending it to the 
> device.  Even using an extra DMA descriptor (as in smc83c170.c) is less 
> efficient.

Are we sure that the mbuf will never point to external storage for small
packets ? At the time I did the fixes, I didn't find anything proving that
this couldn't happen.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--