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.