Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: >> On 3 Mar 2019, at 12:22, John Sager <j...@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 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake