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" wrote: >Kevin Darbyshire-Bryant writes: > >>> On 3 Mar 2019, at 12:22, John Sager 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.