summaryrefslogtreecommitdiffstats
path: root/net/dccp
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2013-10-08 09:02:23 -0700
committerDavid S. Miller <davem@davemloft.net>2013-10-10 00:08:07 -0400
commit8a29111c7ca68d928dfab58636f3f6acf0ac04f7 (patch)
tree3cfc591c8a733e1e8b3d55a3b52caef936022415 /net/dccp
parent4c60f1d67fae632743df9324301e3cb2682f54d4 (diff)
downloadlinux-8a29111c7ca68d928dfab58636f3f6acf0ac04f7.tar.bz2
net: gro: allow to build full sized skb
skb_gro_receive() is currently limited to 16 or 17 MSS per GRO skb, typically 24616 bytes, because it fills up to MAX_SKB_FRAGS frags. It's relatively easy to extend the skb using frag_list to allow more frags to be appended into the last sk_buff. This still builds very efficient skbs, and allows reaching 45 MSS per skb. (45 MSS GRO packet uses one skb plus a frag_list containing 2 additional sk_buff) High speed TCP flows benefit from this extension by lowering TCP stack cpu usage (less packets stored in receive queue, less ACK packets processed) Forwarding setups could be hurt, as such skbs will need to be linearized, although its not a new problem, as GRO could already provide skbs with a frag_list. We could make the 65536 bytes threshold a tunable to mitigate this. (First time we need to linearize skb in skb_needs_linearize(), we could lower the tunable to ~16*1460 so that following skb_gro_receive() calls build smaller skbs) Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/dccp')
0 files changed, 0 insertions, 0 deletions