A comment in include/linux/skbuff.h says that: * Various parts of the networking layer expect at least 32 bytes of * headroom, you should not reduce this.
This was demonstrated by a panic when handling fragmented IPv6 packets: http://marc.info/?l=linux-netdev&m=144236093519172&w=2 It's not entirely clear if that comment is still valid — and if it is, perhaps netif_rx() ought to be enforcing it with a warning. But either way, it is rather stupid from a performance point of view for us to be receiving packets into a buffer which doesn't have enough room to prepend an Ethernet header — it means that *every* incoming packet is going to be need to be reallocated. So let's fix that. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Tested in the DMA code path; I don't believe the DMA-capable devices can still be used in MMIO mode. Simon, Guy, would you be able to test the MMIO version? diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c index 74e18b0..be8225e 100644 --- a/drivers/atm/solos-pci.c +++ b/drivers/atm/solos-pci.c @@ -805,13 +805,13 @@ static void solos_bh(unsigned long card_arg) continue; } - skb = alloc_skb(size + 1, GFP_ATOMIC); + skb = alloc_skb(size + NET_SKB_PAD + 1, GFP_ATOMIC); if (!skb) { if (net_ratelimit()) dev_warn(&card->dev->dev, "Failed to allocate sk_buff for RX\n"); continue; } - + skb_reserve(skb, NET_SKB_PAD); memcpy_fromio(skb_put(skb, size), RX_BUF(card, port) + sizeof(*header), size); @@ -869,8 +869,10 @@ static void solos_bh(unsigned long card_arg) /* Allocate RX skbs for any ports which need them */ if (card->using_dma && card->atmdev[port] && !card->rx_skb[port]) { - struct sk_buff *skb = alloc_skb(RX_DMA_SIZE, GFP_ATOMIC); + struct sk_buff *skb = alloc_skb(RX_DMA_SIZE + NET_SKB_PAD, + GFP_ATOMIC); if (skb) { + skb_reserve(skb, NET_SKB_PAD); SKB_CB(skb)->dma_addr = dma_map_single(&card->dev->dev, skb->data, RX_DMA_SIZE, DMA_FROM_DEVICE); -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature