diff options
author | Eric Dumazet <edumazet@google.com> | 2013-10-08 09:02:23 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-10-10 00:08:07 -0400 |
commit | 8a29111c7ca68d928dfab58636f3f6acf0ac04f7 (patch) | |
tree | 3cfc591c8a733e1e8b3d55a3b52caef936022415 /net/dccp/output.c | |
parent | 4c60f1d67fae632743df9324301e3cb2682f54d4 (diff) | |
download | blackbird-op-linux-8a29111c7ca68d928dfab58636f3f6acf0ac04f7.tar.gz blackbird-op-linux-8a29111c7ca68d928dfab58636f3f6acf0ac04f7.zip |
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/output.c')
0 files changed, 0 insertions, 0 deletions