Re: Linux 2.6.24-rc7

[Jeff Garzik <jeff@garzik.org>]

Linus Torvalds wrote:
> But we shouldn't make up stupid rules like "network drivers *have* to 
> align packets correctly", simply because such rules may not make sense to 
> the driver writer. If the hardware simply cannot do it, or has some 
> horrible performance behaviour when it does so, it's stupid to tell a 
> driver that it has to do it.


<shrug>  seems like it should be possible to have an arch 
copy-and-align-if-necessary hook at the point of packet reception 
(netif_rx or netif_receive_skb).

And it would certainly be a nice cleanup to move all those driver 
implementations of rx_copybreak into common code.

But ultimately the driver knows the hardware (alignment requirements, RX 
skb allocation details) best, so by definition the low-level driver must 
communicate that information /somehow/.

That data may be communicated implicitly, sure:  maybe the 
aforementioned arch hook could simply look at the alignment of the skb's 
data, and make decision based on that (the driver still, by definition, 
ultimately controls RX skb allocation, alignment, and DMA boundaries and 
mappings)

It would be nice to stop maintaining code like the following in 
drivers/net/tulip/tulip_core.c:

> /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */
> #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
>         || defined(CONFIG_SPARC) || defined(__ia64__) \
>         || defined(__sh__) || defined(__mips__)
> static int rx_copybreak = 1518;
> #else
> static int rx_copybreak = 100;
> #endif

The driver passes a lot of information implicitly to the net stack 
simply via its "style" of allocation and mapping.

Its really a question of where you want to pay the cost of unaligned 
accesses, and how much is too much.  If the data is going to be memcpy'd 
to userspace or another buffer almost immediately, maybe we don't even 
care, even on non-x86.

Never know until you bench, I guess...

	Jeff