diff options
author | Eric Dumazet <eric.dumazet@gmail.com> | 2010-10-11 19:05:25 +0000 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2010-10-16 11:13:19 -0700 |
commit | 564824b0c52c34692d804bb6ea214451615b0b50 (patch) | |
tree | d836fa51848026df74e2bec2b634f1fcf3c6d02f /drivers/net | |
parent | 6f0333b8fde44b8c04a53b2461504f0e8f1cebe6 (diff) | |
download | linux-564824b0c52c34692d804bb6ea214451615b0b50.tar.bz2 |
net: allocate skbs on local node
commit b30973f877 (node-aware skb allocation) spread a wrong habit of
allocating net drivers skbs on a given memory node : The one closest to
the NIC hardware. This is wrong because as soon as we try to scale
network stack, we need to use many cpus to handle traffic and hit
slub/slab management on cross-node allocations/frees when these cpus
have to alloc/free skbs bound to a central node.
skb allocated in RX path are ephemeral, they have a very short
lifetime : Extra cost to maintain NUMA affinity is too expensive. What
appeared as a nice idea four years ago is in fact a bad one.
In 2010, NIC hardwares are multiqueue, or we use RPS to spread the load,
and two 10Gb NIC might deliver more than 28 million packets per second,
needing all the available cpus.
Cost of cross-node handling in network and vm stacks outperforms the
small benefit hardware had when doing its DMA transfert in its 'local'
memory node at RX time. Even trying to differentiate the two allocations
done for one skb (the sk_buff on local node, the data part on NIC
hardware node) is not enough to bring good performance.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net')
0 files changed, 0 insertions, 0 deletions