From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 028D43CB35 for ; Mon, 10 Sep 2018 14:52:42 -0400 (EDT) Received: by mail-wm0-x233.google.com with SMTP id y139-v6so22452809wmc.2 for ; Mon, 10 Sep 2018 11:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MWM/DwahBI+QNMibJyj3YQVrlTkOMjf5U1lF1FMIJeQ=; b=Q4ZyyetLR3Tf9EIKWBhf+liuY6lmpOItM5aY1nNmXm531p/GN8OcspAPEvF8+nHeG+ 5TF78E+TH41maH/WUOarSxLVtiDsbeg7e2wOsu9BQtmdeoZnyjL69hg+6nsYIFdYinsp tCjazSPiricZuAirIxfvn8E1sH7cSXl766UuywvhCyUAV0om6+//7Nxy5G5LNa7cnEnb ivr+7BfyclRCJnH9H7rVN048Ly+PPSV0TtfuBl2iBnwmTCcA/tXdiROW8Y4ZPpmZbjvG PjEeOLJ3p3ULqIm8qIZMpNrtHj/dOI4fm2t6gilucyEx7rRaPA+RFD1+MpvgNpS1dcZn efyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MWM/DwahBI+QNMibJyj3YQVrlTkOMjf5U1lF1FMIJeQ=; b=tmra1VSHHw9Vqh2bExe+jGYMknRQ9OKQL3iBo9oVHuDhaD58zo6Ze84yWSspEW2qcG Mrp8rULWYCIkR5RAEWso1m3t+73Ro7BX0/12i6SBan8120DRdrnBJFIko1xHnsZCREgQ mt7HciqJkutZbxuLTahlV5bc8MNsor0ePKSDZJ10i11RMFLVmd5/eUGvxsH4ay2sJPXG 40A9p4hxd7IXIlxfg/zTBxuDd0E3WQI8nHkmqp1ilO6g0oQy72OkVgOR1DWKPLQsgB+l 417aA+KjatBVIGlZIheUAsA8TaQYOO89d0mtR8IW45V7zj4/utcaLejf148GJajSBt/g fWfw== X-Gm-Message-State: APzg51Chvd6pnW3DnK/9t48QRUo14ePIjSQyWTlAZsqHGxxMutTms0yo jTnB7oN2+XcTgK2TaVMbCeaqU2C4 X-Google-Smtp-Source: ANB0VdYPY8otw6kX2hbn2xSfb7BIhn4pTTI7AheXM0+pPkroWrEXVH4/bGmugMFhRi5z3JxuEhSa9g== X-Received: by 2002:a1c:7711:: with SMTP id t17-v6mr1637655wmi.35.1536605561679; Mon, 10 Sep 2018 11:52:41 -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 x24-v6sm30755047wrd.13.2018.09.10.11.52.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 11:52:40 -0700 (PDT) To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , netdev@vger.kernel.org Cc: cake@lists.bufferbloat.net References: <87in3djq45.fsf@toke.dk> From: Eric Dumazet Message-ID: <693f99f0-6876-15bc-2a29-c235e14cc25f@gmail.com> Date: Mon, 10 Sep 2018 11:52:39 -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: <87in3djq45.fsf@toke.dk> 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 18:52:43 -0000 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)