From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DF403CB35 for ; Mon, 4 Mar 2019 06:04:41 -0500 (EST) Received: by mail-ed1-f68.google.com with SMTP id h58so3892893edb.5 for ; Mon, 04 Mar 2019 03:04:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=aBcAKzNUNR2zYS7S2SCwA7L2tZeW45C7KKOW1mC5SiA=; b=SMJgz2qGIfoRWnXRZXirMPigNvNbAsbCaa51SmmRCfAJ/8iQrN2DFlIL20XoMJdmK0 v2SZ3Vwt5SlHcWMQMGslqZ3qr9CshqGgDo2MjV2QnlH/kuCjn35y9gFEdhZHlST1Po/b BVlxKS4Q0gAFf+QiST6/1h/S2TCIzoG/cp2T9Sx9Vqudn30V9I/Wbmh1PTgOl8nXDUYP tYk4DUeOJ/XTMVaHWX+iTZv1X5pWd62I/OfD74Agei3I+wGXtJM2CHQaz3cTTZaDgN1P UwkjVrTwFCp3qcs8pJStBZxbon3d3OTub6sE82Wg3/XsewzPmHAzNdoZSRdED3tJUnM8 QScg== X-Gm-Message-State: APjAAAVPhIIq4YRjAik69OIlsY7SAcd4XWUoXIH/lnItFyhtf1Sw1CUg PP39L7Et+YYApEDPnc+TswtTd88P2x8= X-Google-Smtp-Source: APXvYqx7XcxOty62UmS6K99Bho7zZNvvwnOUPZYsCUWrw7NMnqDLaNG2AzvA3uuVh4Z9sUSsZVdroA== X-Received: by 2002:aa7:df8b:: with SMTP id b11mr14803728edy.166.1551697480538; Mon, 04 Mar 2019 03:04:40 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id j46sm2009971ede.6.2019.03.04.03.04.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 03:04:39 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 45DB8183BB9; Mon, 4 Mar 2019 12:04:39 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Kevin Darbyshire-Bryant , John Sager Cc: "cake\@lists.bufferbloat.net" In-Reply-To: <5B588CD4-D6BA-4BD4-994B-A9CAC8039866@darbyshire-bryant.me.uk> 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 04 Mar 2019 12:04:39 +0100 Message-ID: <87imwylx2w.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:04:41 -0000 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 bi= ts >> of the 32-bit fwmark/connmark space available, rather than the lowest bi= ts. >> Then that would allow to use fwmarks other purposes, and to use the lowe= st >> 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 te= sting. > > That=E2=80=99s a good point and I=E2=80=99m sort of hoping upstream rejec= t the current > submission on that basis. I think the =E2=80=98use of fwmarks=E2=80=99 n= eeds more > thought as to how it=E2=80=99s done for the future - too keen to get some= thing > out. Maybe it=E2=80=99s sufficient as is, I don=E2=80=99t know. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?= id=3D0b5c7efdfc6e389ec6840579fe90bdb6f42b08dc 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