From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lance Richardson Subject: Re: Large performance regression with 6in4 tunnel (sit) Date: Mon, 28 Nov 2016 14:49:47 -0500 (EST) Message-ID: <654673696.7454342.1480362586995.JavaMail.zimbra@redhat.com> References: <20161125120947.142c3af5@canb.auug.org.au> <20161125134520.68ca0969@canb.auug.org.au> <20161127142340.3a5c197e@canb.auug.org.au> <1428298236.4223309.1480355647336.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Sven-Haegar Koch , Eli Cooper , netdev@vger.kernel.org, Eric Dumazet To: Stephen Rothwell Return-path: Received: from mx3-phx2.redhat.com ([209.132.183.24]:57225 "EHLO mx3-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752136AbcK1Tt4 (ORCPT ); Mon, 28 Nov 2016 14:49:56 -0500 In-Reply-To: <1428298236.4223309.1480355647336.JavaMail.zimbra@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: > From: "Lance Richardson" > To: "Stephen Rothwell" > Cc: "Sven-Haegar Koch" , "Eli Cooper" , netdev@vger.kernel.org, "Eric Dumazet" > > Sent: Monday, November 28, 2016 12:54:07 PM > Subject: Re: Large performance regression with 6in4 tunnel (sit) > > > From: "Stephen Rothwell" > > To: "Sven-Haegar Koch" > > Cc: "Eli Cooper" , netdev@vger.kernel.org, "Eric > > Dumazet" > > 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 > > > > wrote: > > > > > > 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 > > > 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 Rothwell > > > > This 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, struct > sock *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