> alloc_skb will always get an skb->data object that is 4 byte aligned.
You mean dev_alloc_skb() I think -- documented as "for sending", (which might be a bug), and reserving an unspecified number of bytes (which is 16 today). Regular alloc_skb() doesn't reserve any bytes, but it does work to guarantee SMP cacheline alignment for skb->head (the buffer). > The reserve adds 2 bytes. This places the ethernet header at > > allocation base 0 > skb->data starts 16 > skb->data after adjust 18 > IP header starts 32 > > Neatly landing the IP header on a cache line start for most processors Color me confused: if a device driver uses dev_alloc_skb() on the send side (per docs) why would aligning the IP header matter? It'd be mucking with link level headers, if anything, and then the skb would be freed without the IP stack ever seeing it. Turns out that at least in the USB net drivers, this logic is all using dev_alloc_skb() on the rx side, contrary to documented intent. So I can at least see that the IP rx processing would get some benefit from it. (Far less than a Gigabit link would, though!) This "why the magic alignment" question has come up before, and it's always been confusing. Partly because it's all voodoo, partly because it's contrary to skbuff.h docs, and partly because the net drivers clearly _work_ without it. Count me in the camp that'd rather get rid of kernel black magic like this. Fixing it might be partially in documentation, and partially in adding a new "ip friendly" dev_alloc_skb for use in the RX path, which encourages that IP header alignment. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
