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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
