<html><head></head><body>Let action connmark continue to do that. You still need mirred anyway.<br><br>John<br><br><br><div class="gmail_quote">On 4 March 2019 11:04:39 GMT, "Toke Høiland-Jørgensen" <toke@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 3 Mar 2019, at 12:22, John Sager <john@sager.me.uk> wrote:<br><br>If you are going to do that, I would suggest using a few of the upper bits<br>of the 32-bit fwmark/connmark space available, rather than the lowest bits.<br>Then that would allow to use fwmarks other purposes, and to use the lowest<br>bits, as well in the future. As iptables allows a mask before comparison,<br>then choose a specific mask for the bits you use both for setting and testing.<br></blockquote><br> That’s a good point and I’m sort of hoping upstream reject the current<br> submission on that basis. I think the ‘use of fwmarks’ needs more<br> thought as to how it’s done for the future - too keen to get something<br> out. Maybe it’s sufficient as is, I don’t know.<br></blockquote><br><a href="https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc">https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc</a><br><br>This means it'll be in 5.1; so we have until that is released (~8 weeks<br>or so) to set the behaviour in stone.<br><br>I do think we at least need to add masking of the mark before using it<br>for tin selection; the question is just which bits to use from it.<br><br>As for setting the fwmark back in conntrack, I'm not sure I agree that<br>this is something CAKE should be doing. Mostly because it means even<br>tighter coupling between CAKE and the conntrack subsystem. However, I<br>may be convinced by a sufficiently neat implementation, and anyway this<br>is definitely something that will need to wait for 5.2 for upstream.<br><br>So I think the priority is to agree on semantics for masking the fwmark<br>when reading, and getting that implemented in a way that is compatible<br>with both other uses of marks, and with anything we else we might want<br>to do down the road.<br><br>-Toke<br><br></pre></blockquote></div><br>-- <br>Sent from the Aether.</body></html>