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>
This commit is contained in:
parent
a02cec2155
commit
59104f0624
|
@ -926,16 +926,19 @@ alloc_new_skb:
|
|||
!(rt->dst.dev->features&NETIF_F_SG))
|
||||
alloclen = mtu;
|
||||
else
|
||||
alloclen = datalen + fragheaderlen;
|
||||
alloclen = fraglen;
|
||||
|
||||
/* The last fragment gets additional space at tail.
|
||||
* Note, with MSG_MORE we overallocate on fragments,
|
||||
* because we have no idea what fragment will be
|
||||
* the last.
|
||||
*/
|
||||
if (datalen == length + fraggap)
|
||||
if (datalen == length + fraggap) {
|
||||
alloclen += rt->dst.trailer_len;
|
||||
|
||||
/* make sure mtu is not reached */
|
||||
if (datalen > mtu - fragheaderlen - rt->dst.trailer_len)
|
||||
datalen -= ALIGN(rt->dst.trailer_len, 8);
|
||||
}
|
||||
if (transhdrlen) {
|
||||
skb = sock_alloc_send_skb(sk,
|
||||
alloclen + hh_len + 15,
|
||||
|
|
Loading…
Reference in New Issue