Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>, netdev@vger.kernel.org
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Corrupted sit-tunnelled packets when using skb_gso_segment() on an IFB interface?
Date: Mon, 10 Sep 2018 11:52:39 -0700	[thread overview]
Message-ID: <693f99f0-6876-15bc-2a29-c235e14cc25f@gmail.com> (raw)
In-Reply-To: <87in3djq45.fsf@toke.dk>



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)



  reply	other threads:[~2018-09-10 18:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 16:04 Toke Høiland-Jørgensen
2018-09-10 18:52 ` Eric Dumazet [this message]
2018-09-10 19:39   ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=693f99f0-6876-15bc-2a29-c235e14cc25f@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=netdev@vger.kernel.org \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox