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.  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
spend as little time as possible in the network stack, but drivers are
already very complicated pieces of code.

I guess the auto-padding stuff could be enclosed in a #ifdef that would be
activated only if you compile in an affected driver.  That way you could
optimize a bit your kernel if you only have padding devices.

Quentin Garnier.