On Sun, Oct 31, 2004 at 02:24:54PM +0100, cube@cubidou.net wrote:
> On Sun, Oct 31, 2004 at 01:33:11PM +0100, Manuel Bouyer wrote:
> > On Sun, Oct 31, 2004 at 12:18:29PM +0100, cube@cubidou.net wrote:
> [...]
> > > Also, I wonder what is the gain of making the padding at
> > > the driver level.  I'd like some input there too.  If
> > > there is no actual advantage to doing that inside the
> > > hardware driver, I think it would be best to convert all
> > > affected drivers to such a scheme as the low-level padding
> > > adds quite some complexity to the driver.
> > 
> > The problem with doing this at the the ethernet level is that
> > it will always cost you extra CPU cycles. 
> 
> Indeed, I'll burn some CPU cycles even when the drivers doesn't need
> the padding.
> 
> > - if the adapter is doing PIO, just write a buch of 0 to the I/O port,
> >   no need to extend the packet. See ne2000.c for an example. This cost less
> >   cpu cycles than setting memory to 0 and then bus_space_write()ing this to
> >   the I/O port.
> > - if the adapter is doing scatter/gather DMA, just add an extra preallocated,
> >   preset to 0 segment at the end. This is almost free in term of CPU cycles.
> >   See if_tl.c for an example.
> > - if the adapter is doing DMA from a fixed preallocated buffer (and the mbuf
> >   chain is copied to this buffer before transmit), just memset the required
> >   space to 0. Again cost less cycles than setting memory to 0 and copying it
> >   to the buffer.
> > - for adapters that autopad themselves, you still add a test in the path.
> > 
> > Now, I don't know if saving these extra CPU cycles is really important or
> > not. When I did the work on this padding problem, it was decided that the
> > best place to do this was in the drivers themselves, because it was the most
> > efficient.
> 
> But it feels so much cleaner that way.

i don't think so. ether_output() doesn't always pass the mbuf to a real
ethernet device (in which case padding may be inappropriate), or to a device
which may have different padding restrictions (does wifi need padding
to ETHER_MIN_LEN ?). Also, packets may come to the adapter's if_snd queue
from other places than ether_output() (if_vlan will do it, as does if_bridge).

> When you told me to look at tl(4)
> code, that's what I did.  But I wasn't able to adapt it to gem(4).  Almost,
> but it simply made the interface fail.  I know that it's very important to

Well, something is wrong then. Either the chip is buggy, or you code wasn't
right. Anyway, it doesn't look right to add bloat to a common piece of
code because one driver in the tree can't handle it.

> spend as little time as possible in the network stack, but drivers are
> already very complicated pieces of code.

The code to add padding doesn't add only a few lines of code, really.

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