Re: Large performance regression with 6in4 tunnel (sit)
From: Lance Richardson <hidden>
Date: 2016-11-28 19:49:56
quoted hunk ↗ jump to hunk
From: "Lance Richardson" <redacted> To: "Stephen Rothwell" <redacted> Cc: "Sven-Haegar Koch" <redacted>, "Eli Cooper" <redacted>, netdev@vger.kernel.org, "Eric Dumazet" [off-list ref] Sent: Monday, November 28, 2016 12:54:07 PM Subject: Re: Large performance regression with 6in4 tunnel (sit)quoted
From: "Stephen Rothwell" <redacted> To: "Sven-Haegar Koch" <redacted> Cc: "Eli Cooper" <redacted>, netdev@vger.kernel.org, "Eric Dumazet" [off-list ref] Sent: Saturday, November 26, 2016 10:23:40 PM Subject: Re: Large performance regression with 6in4 tunnel (sit) Hi Sven-Haegar, On Fri, 25 Nov 2016 05:06:53 +0100 (CET) Sven-Haegar Koch [off-list ref] wrote:quoted
Somehow this problem description really reminds me of a report on netdev a bit ago, which the following patch fixed: commit 9ee6c5dc816aa8256257f2cd4008a9291ec7e985 Author: Lance Richardson [off-list ref] Date: Wed Nov 2 16:36:17 2016 -0400 ipv4: allow local fragmentation in ip_finish_output_gso() Some configurations (e.g. geneve interface with default MTU of 1500 over an ethernet interface with 1500 MTU) result in the transmission of packets that exceed the configured MTU. While this should be considered to be a "bad" configuration, it is still allowed and should not result in the sending of packets that exceed the configured MTU. Could this be related? I suppose it would be difficult to test this patch on this machine?The kernel I am running on is based on 4.7.8, so the above patch doesn't come close to applying. Most fo what it is reverting was introduced in commit 359ebda25aa0 ("net/ipv4: Introduce IPSKB_FRAG_SEGS bit to inet_skb_parm.flags") in v4.8-rc1. -- Cheers, Stephen RothwellThis should be equivalent for 4.7.x:diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 4bd4921..8a253e2 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c@@ -224,8 +224,7 @@ static int ip_finish_output_gso(struct net *net, structsock *sk, int ret = 0; /* common case: locally created skb or seglen is <= mtu */ - if (((IPCB(skb)->flags & IPSKB_FORWARDED) == 0) || - skb_gso_network_seglen(skb) <= mtu) + if (skb_gso_network_seglen(skb) <= mtu) return ip_finish_output2(net, sk, skb); /* Slowpath - GSO segment length is exceeding the dst MTU.
BTW, I do think this would be worth trying. For the geneve case, I measured on the order of a 10X-100X performance hit without this patch, traces were similar to what you describe (too-large gso packets were dropped, corresponding TCP segments were retransmitted later via a non-gso code path). Regards, Lance