From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Ryan Mounce <ryan@mounce.com.au>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Hopefully fixed ACK filter for v6
Date: Sun, 29 Apr 2018 12:45:26 +0200 [thread overview]
Message-ID: <36AF888D-0AE5-4062-99FC-A6DB9CFA75D3@toke.dk> (raw)
In-Reply-To: <CAN+fvRbDemV5+tyrg_SX78xfZmxG2Sche6sU9_uB48rNU2A2cg@mail.gmail.com>
On 29 April 2018 03:01:55 CEST, Ryan Mounce <ryan@mounce.com.au> wrote:
>On 29 April 2018 at 07:19, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Think I finally managed to fix the ACK filter so it works for both
>6in4
>> and regular v6 (the latter seems to have been broken since the commit
>> "e6b72c2 ack_filter: make less aggressive by default" which
>accidentally
>> reversed the address compare logic). It should also be safe against
>> weirdly fragmented packets (ha! famous last words!).
>>
>> If someone wants to either eyeball the code and/or test the ACK
>filter
>> please do. I'm planning to resubmit the patch to netdev sometime
>> tomorrow evening :)
>
>Eyeballing now, only a couple of comments.
>
>- Initialisation of iph and ipv6h can be moved before the while()
>loop. The compiler probably does this anyway.
Yeah, figured I'd let the compiler deal with that...
>- Whether it is worth the complexity of restoring the
>skb->encapsulation check within cake_get_tcphdr to handle other cases
>of encapsulated v4/v6 traffic. I may find some time to test this later
>today.
The reason I removed the check for skb->encapsulation was that in my tests it wasn't actually set for 6in4 traffic.
And looking at the code that touches it, that field seems to mostly be related to offloads? Or did you actually see any effect of using it when you added it initially? :P
>Everything else looks good to me, much cleaner.
Awesome, thanks for taking a look!
>Thank you so much for your efforts so far in getting cake upstream,
>and in particular to rescue ACK filtering. We may have to send you a
>real cake!
Haha, you're very welcome. Real cake will be appreciated, but don't feel any obligations ;)
-Toke
next prev parent reply other threads:[~2018-04-29 10:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-28 21:49 Toke Høiland-Jørgensen
2018-04-29 1:01 ` Ryan Mounce
2018-04-29 10:45 ` Toke Høiland-Jørgensen [this message]
2018-04-29 11:38 ` Jonathan Morton
2018-04-29 11:40 ` Sebastian Moeller
2018-04-29 14:25 ` Toke Høiland-Jørgensen
2018-05-04 22:38 ` Jonathan Morton
2018-05-06 15:35 ` Toke Høiland-Jørgensen
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=36AF888D-0AE5-4062-99FC-A6DB9CFA75D3@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=ryan@mounce.com.au \
/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