if_tap unaligned access problem

Sten Spans sten at blinkenlights.nl
Mon May 2 16:35:41 PDT 2005


On Mon, 2 May 2005, Mike Silbersack wrote:

>
> On Thu, 28 Apr 2005, Bruce M Simpson wrote:
>
>> jmg's suggestion of bringing in the NetBSD patches to allow the entire
>> network stack to be compiled with unaligned accesses (for those platforms
>> which support it) is interesting because it can simplify or eliminate
>> some of the acrobatics needed in network drivers to deal with the mbuf
>> alignment.
>
> I'm too lazy to benchmark, but I suspect that having the ethernet code shift 
> the packet backwards by two bytes after it strips off the ethernet header is 
> going to be faster than requiring ip_input to allocate a new mbuf for each 
> received packet.
>
> Such a change would also ensure that we don't break all the other protocols 
> that jmg didn't touch in his patch.

For the if_tap case fixing the driver ( or rather changing m_uiotombuf )
is definately the correct solution. No sensible person would say otherwise.
Once the if_tap change is properly tested and signed off it should
make it into the tree.

But on the proposed alignment changes:

If you would look at the netbsd url (
http://mail-index.netbsd.org/source-changes/2002/07/01/0001.html )

You would see that:

1- This code only triggers for strict alignment architectures
    No inpact for i386 and amd64.

2- This code only triggers when the protocol header is unaligned.
    If the l2 driver is ok then this code won't be triggered.

3- Only the link headers are aligned, not the entire mbuf(chain).
    This should limit the performance impact quite a bit.
    It might even alow us to eliminate quite a bit of ugly
    mbuf juggling in certain drivers.
    http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_input.c.diff?r1=1.153&r2=1.154&f=h
    ( Or the comments are incorrect, and I need to do more code reading :)

To summarize:

These changes will stop kernel crashes on alpha and sparc for drivers
which are currently broken. All the drivers which currently work
will not trigger this code.

I haven't looked at every drivers but this change looks quite
a bit cleaner than most of the tricks pulled in ethernet drivers,
especially when jumboframes are involved.


Netbsd has had 3 years to test this code, it can't be all bad :)

-- 
Sten Spans

"There is a crack in everything, that's how the light gets in."
Leonard Cohen - Anthem


More information about the freebsd-net mailing list