Subject: Ethernet frame padding changes
To: None <tech-kern@netbsd.org>
From: Charles M. Hannum <abuse@spamalicious.com>
List: tech-kern
Date: 07/06/2004 04:10:11
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.