summaryrefslogtreecommitdiffstats
path: root/drivers/net/ixgbe
diff options
context:
space:
mode:
authorSaeed Bishara <saeed@marvell.com>2010-01-05 09:15:32 +0000
committerDavid S. Miller <davem@davemloft.net>2010-01-07 01:11:10 -0800
commit530e557ab268de154609f3cce2f2390e7b195af3 (patch)
treec0601d18875bfee5acd242fbc0f19cb4d6dac974 /drivers/net/ixgbe
parent2467ab9590092ffdf837e9283e84dedd04c93ab3 (diff)
downloadlinux-530e557ab268de154609f3cce2f2390e7b195af3.tar.gz
linux-530e557ab268de154609f3cce2f2390e7b195af3.tar.bz2
linux-530e557ab268de154609f3cce2f2390e7b195af3.zip
mv643xx_eth: don't include cache padding in rx desc buffer size
If NET_SKB_PAD is not a multiple of the cache line size, mv643xx_eth allocates a couple of extra bytes at the start of each receive buffer to make the data payload end up on a cache line boundary. These extra bytes are skb_reserve()'d before DMA mapping, so they should not be included in the DMA map byte count (as the mapping is done starting at skb->data), nor should they be included in the receive descriptor buffer size field, or the hardware can end up DMAing beyond the end of the buffer, which can happen if someone sends us a larger-than-MTU sized packet. This problem was introduced in commit 7fd96ce47ff ("mv643xx_eth: rework receive skb cache alignment", May 6 2009), but hasn't appeared to be problematic so far, probably as the main users of mv643xx_eth all have NET_SKB_PAD == L1_CACHE_BYTES. Signed-off-by: Saeed Bishara <saeed@marvell.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ixgbe')
0 files changed, 0 insertions, 0 deletions