From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) (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 96EBE3B2A4 for ; Mon, 11 Mar 2019 10:32:19 -0400 (EDT) Received: by mail-ed1-f66.google.com with SMTP id a16so4219312edn.1 for ; Mon, 11 Mar 2019 07:32:19 -0700 (PDT) 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=kT+CFUG1YU2zgYBFp5THXdt5kOzxbnAb27CGHk/RBtE=; b=CdZKAKk1eTD9TXkPQVsWUz9KylDvlbT941mBj4CfiBP3C9LB+AVSyg1MjJPj35elpl xLo51KmnQvWxHm6fQ7rOqBx9TkG3ENWEnJUPZRQQalX4tCsQEikFDGriWzVbjde9kbpo xK34o9v47moZjeyAnHNrOMUNgfUZhs0I08DGQSF1r0dg1MhVmdZ3FcuPwRlmDWs0eiiK 9rrZODFWUw+/T7vKd+80Gtz3KUaQ7kY8HRf9Jbb4mklw6WfcOlo6yTxE1CyUk7k2HgOL +du0FmCT0B0Ivi+2fPWCbpKC5PTorItk+iMh9yW0mMlvPXDSel2ONLK/w7vmuKVeQlgW /alg== X-Gm-Message-State: APjAAAXjQtQJCVVWxJPLaQNoyozQWKeIgE/rBgnX0/CXHe2lDYHOPnZV MzC/HLBlyMW9EFSdMQmzRqE1qhPNex0= X-Google-Smtp-Source: APXvYqwPmmZ/1sZAIhOZoLx9JtatTHOSrArL8N8e7Q1S6nFe3YzWMT+ia7soYwtwYdbg6Susq0W1WQ== X-Received: by 2002:a50:d1c8:: with SMTP id i8mr42789141edg.207.1552314738672; Mon, 11 Mar 2019 07:32:18 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id f9sm1265174eds.56.2019.03.11.07.32.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Mar 2019 07:32:17 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 85999180454; Mon, 11 Mar 2019 15:32:17 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Kevin Darbyshire-Bryant Cc: "cake\@lists.bufferbloat.net" In-Reply-To: References: <875zsw110r.fsf@toke.dk> <6B530473-971A-4265-B94B-3595D39D57AF@darbyshire-bryant.me.uk> <87r2bjyoyn.fsf@toke.dk> <4505E3A0-6AE2-4C0B-960D-B1EDB616F0CA@darbyshire-bryant.me.uk> <878sxq1t3e.fsf@toke.dk> <00E839ED-7FA4-4577-838F-775EC9A90608@darbyshire-bryant.me.uk> <871s3h7ghi.fsf@toke.dk> <7FFADD0C-591A-4BB4-B96C-C0157963E1EB@darbyshire-bryant.me.uk> <87ef7g5eec.fsf@toke.dk> <87imwq4724.fsf@toke.dk> <1D3F7894-4A8F-4D57-BE27-18113FB14131@darbyshire-bryant.me.uk> <875zsp4lc5.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 11 Mar 2019 15:32:17 +0100 Message-ID: <8736nt4h3i.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] act_connmark + dscp 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, 11 Mar 2019 14:32:19 -0000 Kevin Darbyshire-Bryant writes: >> On 11 Mar 2019, at 13:00, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Kevin Darbyshire-Bryant writes: >>=20 >>>>> The ugliness of doing the diffserv parsing is what prompted the idea >>>>> of storing the DSCP directly and I felt the stored tin selection was >>>>> effectively abstracting the diffserv field anyway. >>>>=20 >>>> Right, but that means that the CAKE interpretation of the fwmark would >>>> have to change from something that selects the tin, to something that = is >>>> treated as a DSCP mark. I think this was the part that I was missing >>>> before. I don't think this is a good idea, as that means we tie the >>>> marks to one particular use case. >>>=20 >>> I did say it was incompatible with the existing tin storing idea right >>> from day 1 and why I was so keen/worried by the fact it had already >>> gone upstream. >>=20 >> Yeah, but I didn't connect the dots for how this related to the CAKE use >> case until I saw your full example... >>=20 >>>>> Storing the DSCP is more compatible with differing egress v ingress >>>>> mappings (eg. egress diffserv4, ingress diffserv3 though I can=E2=80= =99t >>>>> really think of a use case for that) >>>>=20 >>>> I think that if someone wants to do something like that, we are way out >>>> of "simple use case that we want to actively support" territory, and c= an >>>> legitimately ask people to go write a BPF filter or something :) >>>>=20 >>>>> Of course using fwmark as tin number selector in cake doesn=E2=80=99t= preclude >>>>> some other mechanism of storing & recovering DSCP to/from firewall >>>>> mark e.g. the previously discussed act-connmark+dscp which would help >>>>> anyone who wanted to do such =E2=80=98link traversing=E2=80=99 DSCP s= henanigans. That >>>>> of course makes you happier since cake doesn=E2=80=99t embed itself f= urther >>>>> into conntrack. >>>>=20 >>>> Yeah, I definitely don't think CAKE has any business writing DSCP valu= es >>>> into the mark. However, as I said before, there may be a case for addi= ng >>>=20 >>> I=E2=80=99m going forward on the basis that *cake* =E2=80=99storing DSC= P within >>> fwmark=E2=80=99 idea has died and will be trying to cobble something to= gether >>> within act_connmark as that has a wider potential client base than >>> just cake. >>=20 >> Yup, sounds good. >>=20 >> BTW, for future reference, while digging through the TC eBPF code, I >> discovered that it is (I think) possible to indirectly pass information >> to the eBPF program: If you add a classid when adding the bpf filter, >> the kernel will put that into skb->tc_classid before executing the eBPF >> program. This serves as a default if you don't do any classification >> from the eBPF program, but presumably you can also just read and modify >> it from the eBPF program=E2=80=A6 > > I=E2=80=99ll try to remember that if I=E2=80=99m ever in the eBPF vicinit= y. > > >>=20 >>>> an option to write the tin selection back to conntrack. Something like >>>> the patch below would do it (with an option to control it, of course), >>>> but it does incur a dependency on another conntrack header, so I'm not >>>> sure if it will be acceptable to upstream. Also, we would need to figu= re >>>> out how the option should work. >>>=20 >>> I think before expending any further mental effort on that, the >>> question should be asked of the kernel people. I don=E2=80=99t see the= point >>> in working out the semantics of something that ultimately won=E2=80=99t= be >>> accepted. >>=20 >> Unfortunately that is not how upstream development works. If we want >> this feature, we're going to have to do the work of defining and >> implementing it and make our case that it should be included. >>=20 >> I think a possible way forward would be: >>=20 >> 1. I'll submit the masking patch for the existing fwmark feature to >> upstream. That should get in this cycle, and will form the basis for >> anything else we want to do in the future. > > Agreed. Masking should have been in the original patch. Had I known > about (and been amused by) ffs it would have been done :-) Indeed, I also had a chuckle over the function name :D >> 2. For the next cycle (i.e., upstream 5.2) we can hash out what we >> really need for this use case, and how it should work from a user >> perspective; we're going to need that anyway even if we end up >> implementing it differently. This also includes deciding on whether >> this is doable outside of CAKE, or if we need another feature flag. > > You=E2=80=99ve already clearly demonstrated that the marking/flagging can= be > done using iptables, so it is doable outside of CAKE. The iptables > rules to do it outside of CAKE are=E2=80=A6an unpleasant way of implement= ing a > lookup table which also requires knowledge of the inner workings of > CAKE (lookup table & tin order). Personally I feel that=E2=80=99s ugly, b= ut > you already know that :-) Yeah, you basically summed up the argument I am planning to use to get it accepted :) >> 3. We submit whatever we come up with. If it gets accepted, great, >> otherwise we iterate based on feedback. > > I await the tarring & feathering followed by =E2=80=9CYou=E2=80=99re tryi= ng to set a > conntrack mark=E2=80=A6=E2=80=A6from a QDISC?!!!!!! get outta town=E2=80= =9D :-) Haha, yup, should be fun! -Toke