From: John Sager <john@sager.me.uk>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"Kevin Darbyshire-Bryant" <kevin@darbyshire-bryant.me.uk>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Using firewall connmarks as tin selectors
Date: Mon, 04 Mar 2019 11:39:55 +0000 [thread overview]
Message-ID: <C66E2BF5-C489-4EA2-89AA-272324E44FA6@sager.me.uk> (raw)
In-Reply-To: <87imwylx2w.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
Let action connmark continue to do that. You still need mirred anyway.
John
On 4 March 2019 11:04:39 GMT, "Toke Høiland-Jørgensen" <toke@redhat.com> wrote:
>Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
>>> On 3 Mar 2019, at 12:22, John Sager <john@sager.me.uk> wrote:
>>>
>>> If you are going to do that, I would suggest using a few of the
>upper bits
>>> of the 32-bit fwmark/connmark space available, rather than the
>lowest bits.
>>> Then that would allow to use fwmarks other purposes, and to use the
>lowest
>>> bits, as well in the future. As iptables allows a mask before
>comparison,
>>> then choose a specific mask for the bits you use both for setting
>and testing.
>>
>> That’s a good point and I’m sort of hoping upstream reject the
>current
>> submission on that basis. I think the ‘use of fwmarks’ needs more
>> thought as to how it’s done for the future - too keen to get
>something
>> out. Maybe it’s sufficient as is, I don’t know.
>
>https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc
>
>This means it'll be in 5.1; so we have until that is released (~8 weeks
>or so) to set the behaviour in stone.
>
>I do think we at least need to add masking of the mark before using it
>for tin selection; the question is just which bits to use from it.
>
>As for setting the fwmark back in conntrack, I'm not sure I agree that
>this is something CAKE should be doing. Mostly because it means even
>tighter coupling between CAKE and the conntrack subsystem. However, I
>may be convinced by a sufficiently neat implementation, and anyway this
>is definitely something that will need to wait for 5.2 for upstream.
>
>So I think the priority is to agree on semantics for masking the fwmark
>when reading, and getting that implemented in a way that is compatible
>with both other uses of marks, and with anything we else we might want
>to do down the road.
>
>-Toke
--
Sent from the Aether.
[-- Attachment #2: Type: text/html, Size: 2718 bytes --]
next prev parent reply other threads:[~2019-03-04 11:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 21:12 Felix Resch
2019-02-28 3:24 ` gamanakis
2019-03-03 11:52 ` Kevin Darbyshire-Bryant
2019-03-03 12:22 ` John Sager
2019-03-03 16:25 ` Kevin Darbyshire-Bryant
2019-03-04 11:04 ` Toke Høiland-Jørgensen
2019-03-04 11:39 ` John Sager [this message]
2019-03-04 5:37 ` Ryan Mounce
2019-03-04 6:31 ` Jonathan Morton
2019-03-04 6:37 ` Ryan Mounce
2019-03-04 7:15 ` Dave Taht
2019-03-04 8:39 ` Pete Heist
2019-03-04 11:01 ` Kevin Darbyshire-Bryant
2019-03-04 11:17 ` Toke Høiland-Jørgensen
2019-03-04 11:55 ` Kevin Darbyshire-Bryant
2019-03-04 12:44 ` Toke Høiland-Jørgensen
2019-03-04 15:50 ` Kevin Darbyshire-Bryant
2019-03-04 16:39 ` Toke Høiland-Jørgensen
2019-03-04 17:19 ` Kevin Darbyshire-Bryant
2019-03-04 17:36 ` Toke Høiland-Jørgensen
2019-03-04 20:58 ` Kevin Darbyshire-Bryant
2019-03-04 21:33 ` Toke Høiland-Jørgensen
2019-03-04 21:42 ` Toke Høiland-Jørgensen
2019-03-05 14:06 ` Kevin Darbyshire-Bryant
-- strict thread matches above, loose matches on Subject: below --
2019-02-27 14:52 Kevin Darbyshire-Bryant
2019-02-27 15:14 ` Toke Høiland-Jørgensen
2019-02-28 8:32 ` Kevin Darbyshire-Bryant
2019-02-28 9:54 ` Toke Høiland-Jørgensen
2019-02-28 11:00 ` Kevin Darbyshire-Bryant
2019-02-28 11:13 ` 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=C66E2BF5-C489-4EA2-89AA-272324E44FA6@sager.me.uk \
--to=john@sager.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
--cc=toke@redhat.com \
/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