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