Re: Linux 2.6.24-rc7

[Jeff Garzik <jeff@garzik.org>]

Linus Torvalds wrote:
> 
> On Fri, 25 Jan 2008, Michael Buesch wrote:
>> The problem is _not_ the wireless header access, but the alignment of the embedded
>> protocol stack, if the header does not have a size aligned to 4.
>> Do we want to clutter the whole networking stack below wireless with
>> get_unaligned() or attribute(packed) or something like that?
> 
> That's what all the other protocols do, isn't it?
> 
> For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma* 
> from the card should be aligned, even if that in turn means that the IP 
> payload itself is then just two-byte aligned rather than word-aligned 
> (14-byte ethernet headers and all that).
> 
> [ Side note - I _used_ to know the networking code. That was about eight 
>   to ten years ago. I'm really happy having a maintainer for it and not 
>   having to know all the details any more, so maybe things have changed. ]
> 
> I do think that we generally should try to make the drivers do as little 
> complex stuff as humanly possible, and expect as little from hardware (and 
> firmware counts in that group) as we can. If some higher-level thing 
> really needs things aligned in order to not have to have lots of ugly 
> code, it should generally extract that alignment itself.

Actually...  grep for rx_copybreak in networking drivers.

For certain ethernet NIC hardware, given standard packet headers, your 
data will always be unaligned, which -does- have a cost, even on Intel. 
  On such hardware, this is required because the RX packet must start on 
a 32-bit (sometimes 64-bit) DMA boundary.

Since RX SKBs are pre-allocated, we use the driver-wide 'rx_copybreak' 
variable to determine the point at which an unaligned packet is painful 
enough that we should copy into a newly allocated, properly aligned skb 
(NET_IP_ALIGN, etc.)

Sane architectures can set rx_copybreak to MTU size.  Other 
architectures (at compile time) set the rx_copybreak default to 
something smaller.

	Jeff