From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E53AB3CB35 for ; Mon, 10 Sep 2018 15:39:59 -0400 (EDT) Received: by mail-wm0-x22f.google.com with SMTP id t25-v6so22604524wmi.3 for ; Mon, 10 Sep 2018 12:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jInWM3B9sz7sDwMCa0JoXNyxCwKDAnevouGYcrm3Rt0=; b=mTp31s4R9UnxRY/DQv03YYjZpaRoUgbN8vgCi23fT+ZIGKClNR8kbG55TycgITbYx7 TlFwjJLiWAyoh0xNsqe3Rm8kB4m616jPqxGIOJ+BO6WWqI3rw9ljh3EuoR92xD9FaGTq d1WmHsxLwZl4uRB/e6ErMa2JBgxUdTcps5f+vx/C+IXLmZ96caR2RWcNXAheABpfmlMP ChM+XamOKzL/6hhg4Fx5yd1TckCEm/OG0bV3ZCPcE0P77U4kvQuq8Wz3kugu++Ro18EG XtD25+VghlyS/Zlt0GLuIusB4bVNaCXFZ3DtmhbtZAS3F+gXAOEJS4LX37Ry2ijGk/X+ Er1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jInWM3B9sz7sDwMCa0JoXNyxCwKDAnevouGYcrm3Rt0=; b=ViPCFeLcikWjaBfPbZSWquZMynT7hDv0JFW8FpykiQAHQb+FMis0yY9GiM7LkQhcWC NMtUme8q0u3PPu1g7TNWxmIgVAlCYVl3iVrhStBHeEhhv7s7L0AkZR+vvWaXEwUFkidZ VXl9rerGGONnvdOLieFSVsB64SSuklJBe9ihyI/4ZAguF5Cv+6sb0sW5a06Vt8WEku/m yU+luRawnTcSSq5r815hkooaZmkIxXpNgEQIs4QpWFPCzVUDsrwGU1IJ8JMpfx5o/TkZ OQPlPldddQUtH2Wx3n2rF59AMjd4Ulta/MJTCuA1IhdXBpptHQPXY0ZEdYwF0OdMvU3K StCg== X-Gm-Message-State: APzg51CoNoHD4UVWwJcm14pFiYDiVR63rRPnT7PwDj5PIwk6oplVbhOl g8exf4QyFaTD8t7uOPPzkho= X-Google-Smtp-Source: ANB0VdaFmbNFT02B5WEwk4TlbT1gwf9jSoJur+w5xOAlOBh3bb0p0PkXWkjXtNqVxDfIUN9hHgj39g== X-Received: by 2002:a1c:e0d7:: with SMTP id x206-v6mr1813686wmg.74.1536608398911; Mon, 10 Sep 2018 12:39:58 -0700 (PDT) Received: from [192.168.8.147] (221.198.136.77.rev.sfr.net. [77.136.198.221]) by smtp.gmail.com with ESMTPSA id z11-v6sm21722558wrm.94.2018.09.10.12.39.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 12:39:57 -0700 (PDT) From: Eric Dumazet To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , netdev@vger.kernel.org Cc: cake@lists.bufferbloat.net, Herbert Xu References: <87in3djq45.fsf@toke.dk> <693f99f0-6876-15bc-2a29-c235e14cc25f@gmail.com> Message-ID: Date: Mon, 10 Sep 2018 12:39:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <693f99f0-6876-15bc-2a29-c235e14cc25f@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Cake] Corrupted sit-tunnelled packets when using skb_gso_segment() on an IFB interface? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 19:40:00 -0000 On 09/10/2018 11:52 AM, Eric Dumazet wrote: > > > On 09/10/2018 09:04 AM, Toke Høiland-Jørgensen wrote: >> Hi everyone >> >> While investigating a bug report on CAKE[0], I've run into the following >> behaviour: >> >> When running CAKE as an ingress shaper on an IFB interface, if the GSO >> splitting feature is turned on, TCP throughput will drop dramatically on >> 6in4 (sit) tunnels running over the interface in question. Looking at a >> traffic dump, I'm seeing ~15% packet loss on the encapsulated TCP >> stream. >> >> IPv4 traffic is fine on the same interface, as is native IPv6 traffic. >> And turning off GSO splitting in CAKE makes the packet loss go away. The >> issue only seems to appear on IFB interfaces. So I'm wondering if there >> is some interaction that corrupts packets when they are being split in >> this configuration? >> >> Steps to reproduce (assuming the box you are running on has IP 10.0.0.2 >> on eth0, and has a peer at 10.0.0.1 with a suitably configured sit >> tunnel): >> >> # modprobe ifb >> # ip link set dev ifb0 up >> # tc qdisc add dev eth0 handle ffff: ingress >> # tc filter add dev eth0 parent ffff: protocol all prio 10 matchall action mirred egress redirect dev ifb0 >> # tc qdisc replace dev ifb0 root cake >> # ip link add type sit local 10.0.0.2 remote 10.0.0.1 >> # ip link set dev sit1 up >> # netperf -H fe80::a00:1%sit1 -t TCP_MAERTS >> >> Whereas, in the same setup, this will work fine: >> >> # netperf -H 10.0.0.1 -t TCP_MAERTS >> >> As will this: >> >> # tc qdisc replace dev ifb0 root cake no-split-gso >> # netperf -H fe80::a00:1%sit1 -t TCP_MAERTS >> >> >> Does anyone have any ideas? :) >> > > My guess is that skb->mac_len is not properly updated in the segments (compared to the original GSO packet) And the skb->mac_len being not properly set is a problem after commit f40ae91307c275fc8b17420fa74145e9937c3c0b act_mirred: Fix bogus header when redirecting from VLAN