On Tuesday 06 July 2004 10:03, Manuel Bouyer wrote:
> 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.

There's no absolute guarantee of that, but that doesn't prevent making the 
common case optimal.