ip: take care of last fragment in ip_append_data
authorEric Dumazet <eric.dumazet@gmail.com>
Mon, 20 Sep 2010 20:16:27 +0000 (20:16 +0000)
committerDavid S. Miller <davem@davemloft.net>
Fri, 24 Sep 2010 21:41:04 +0000 (14:41 -0700)
commit59104f062435c7816e39ee5ed504a69cb8037f10
treecc77c6202d01b9c152634b836fa06e77b27d14fc
parenta02cec2155fbea457eca8881870fd2de1a4c4c76
ip: take care of last fragment in ip_append_data

While investigating a bit, I found ip_fragment() slow path was taken
because ip_append_data() provides following layout for a send(MTU +
N*(MTU - 20)) syscall :

- one skb with 1500 (mtu) bytes
- N fragments of 1480 (mtu-20) bytes (before adding IP header)
last fragment gets 17 bytes of trail data because of following bit:

if (datalen == length + fraggap)
alloclen += rt->dst.trailer_len;

Then esp4 adds 16 bytes of data (while trailer_len is 17... hmm...
another bug ?)

In ip_fragment(), we notice last fragment is too big (1496 + 20) > mtu,
so we take slow path, building another skb chain.

In order to avoid taking slow path, we should correct ip_append_data()
to make sure last fragment has real trail space, under mtu...

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/ip_output.c