From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail70c50.megamailservers.eu (mail76c50.megamailservers.eu [91.136.10.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6AB6F3B29E for ; Mon, 4 Mar 2019 06:40:02 -0500 (EST) X-Authenticated-User: sagermail@sager.me.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1551699599; bh=CPsFXz/R9GrncEkggtPdiDaSNWkDVzc7ekRSEKbLJB8=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=KjshRv0cIfzP3W+Gwllwn4lHnCBZe/RITyoCHPdmpqII4nOeFcIsxlY5bG7+1XT86 Y8+eP5X2VfJIwNSaMpljOMde6dLnR8TfgR22GchdAO20s+VFqP4tHtMWhJY4dSbLa1 NoSjxdw10ttor6lwP4w8wWM8P31hrY88ufbItDp0= Feedback-ID: john@sager.me.u Received: from mainserver.wc (97.83.2.81.in-addr.arpa [81.2.83.97]) (authenticated bits=0) by mail70c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x24BdvGJ018589 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Mar 2019 11:39:59 +0000 Received: from [192.168.240.4] by mainserver.wc with esmtp (Exim 4.86_2) (envelope-from ) id 1h0lwr-0005GO-0g; Mon, 04 Mar 2019 11:39:57 +0000 Date: Mon, 04 Mar 2019 11:39:55 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <87imwylx2w.fsf@toke.dk> References: <1443315187.406067.1551301968084@webmail.strato.de> <000901d4cf15$27748ec0$765dac40$@gmail.com> <67E78212-F68E-4BD1-946D-F1830EEA2968@darbyshire-bryant.me.uk> <5B588CD4-D6BA-4BD4-994B-A9CAC8039866@darbyshire-bryant.me.uk> <87imwylx2w.fsf@toke.dk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----AP6ODZR5918HK2WIIXF970QAKIAFJU" Content-Transfer-Encoding: 7bit To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , Kevin Darbyshire-Bryant CC: "cake@lists.bufferbloat.net" From: John Sager Message-ID: X-CTCH-RefID: str=0001.0A0B0204.5C7D0E8F.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=ILcs9DnG c=1 sm=1 tr=0 a=dws6IJh5fU+Ftmrx3Eq8JA==:117 a=dws6IJh5fU+Ftmrx3Eq8JA==:17 a=NTGMnVQrEZIA:10 a=20KFwNOVAAAA:8 a=SxEtWCb9AAAA:8 a=GQ3UrkdYAAAA:8 a=VwQbUJbxAAAA:8 a=UfrW5kvikoN1cskJaa0A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=B3SAHmnYiXxViiFv:21 a=C1gdPjtb22lE40wk:21 a=QEXdDO2ut3YA:10 a=B5ay_9PKMDkA:10 a=_yEWsRYk3IATDM65ZCkA:9 a=zjEgtbyOhoX7imtC:21 a=G18TpxDJH0zD16T9:21 a=85-kbrMXcZ5hEPFk:21 a=_W_S_7VecoQA:10 a=nmmqd-WjEVsm9Gjy6SiX:22 a=UrkXBYOGhgNlFfmH13Sb:22 a=AjGcO6oz07-iQ99wixmX:22 Subject: Re: [Cake] Using firewall connmarks as tin selectors X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 11:40:02 -0000 ------AP6ODZR5918HK2WIIXF970QAKIAFJU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let action connmark continue to do that=2E You still need mirred anyway=2E John On 4 March 2019 11:04:39 GMT, "Toke H=C3=B8iland-J=C3=B8rgensen" wrote: >Kevin Darbyshire-Bryant writes: > >>> On 3 Mar 2019, at 12:22, John Sager wrote: >>>=20 >>> 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=2E >>> Then that would allow to use fwmarks other purposes, and to use the >lowest >>> bits, as well in the future=2E As iptables allows a mask before >comparison, >>> then choose a specific mask for the bits you use both for setting >and testing=2E >> >> That=E2=80=99s a good point and I=E2=80=99m sort of hoping upstream rej= ect the >current >> submission on that basis=2E I think the =E2=80=98use of fwmarks=E2=80= =99 needs more >> thought as to how it=E2=80=99s done for the future - too keen to get >something >> out=2E Maybe it=E2=80=99s sufficient as is, I don=E2=80=99t know=2E > >https://git=2Ekernel=2Eorg/pub/scm/linux/kernel/git/davem/net-next=2Egit/= commit/?id=3D0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc > >This means it'll be in 5=2E1; so we have until that is released (~8 weeks >or so) to set the behaviour in stone=2E > >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=2E > >As for setting the fwmark back in conntrack, I'm not sure I agree that >this is something CAKE should be doing=2E Mostly because it means even >tighter coupling between CAKE and the conntrack subsystem=2E However, I >may be convinced by a sufficiently neat implementation, and anyway this >is definitely something that will need to wait for 5=2E2 for upstream=2E > >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=2E > >-Toke --=20 Sent from the Aether=2E ------AP6ODZR5918HK2WIIXF970QAKIAFJU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let action connmark continue to do that=2E You sti= ll need mirred anyway=2E

John


= On 4 March 2019 11:04:39 GMT, "Toke H=C3=B8iland-J=C3=B8rgensen" <toke@r= edhat=2Ecom> wrote:
Kevin Darbyshire-Bryant <kevin@darbyshire-bryant=
=2Eme=2Euk> writes:

On 3 Mar 2019, at 12:2=
2, John Sager <john@sager=2Eme=2Euk> wrote:

If you are going t=
o do that, I would suggest using a few of the upper bits
of the 32-bit f=
wmark/connmark space available, rather than the lowest bits=2E
Then that=
 would allow to use fwmarks other purposes, and to use the lowest
bits, =
as well in the future=2E As iptables allows a mask before comparison,
th=
en choose a specific mask for the bits you use both for setting and testing=
=2E

 That=E2=80=99s a good point and I=E2=80=99m sort o=
f hoping upstream reject the current
 submission on that basis=2E  I thi=
nk the =E2=80=98use of fwmarks=E2=80=99 needs more
 thought as to how it=
=E2=80=99s done for the future - too keen to get something
 out=2E  Mayb=
e it=E2=80=99s sufficient as is, I don=E2=80=99t know=2E
https://g=
it=2Ekernel=2Eorg/pub/scm/linux/kernel/git/davem/net-next=2Egit/commit/?id=
=3D0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc

This means it'll be =
in 5=2E1; so we have until that is released (~8 weeks
or so) to set the =
behaviour in stone=2E

I do think we at least need to add masking of =
the mark before using it
for tin selection; the question is just which b=
its to use from it=2E

As for setting the fwmark back in conntrack, I=
'm not sure I agree that
this is something CAKE should be doing=2E Mostl=
y because it means even
tighter coupling between CAKE and the conntrack =
subsystem=2E However, I
may be convinced by a sufficiently neat implemen=
tation, and anyway this
is definitely something that will need to wait f=
or 5=2E2 for upstream=2E

So I think the priority is to agree on sema=
ntics for masking the fwmark
when reading, and getting that implemented =
in a way that is compatible
with both other uses of marks, and with anyt=
hing we else we might want
to do down the road=2E

-Toke


--
Sent from the Aether=2E ------AP6ODZR5918HK2WIIXF970QAKIAFJU--