From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 9B4853B2A4 for ; Mon, 11 Mar 2019 09:00:44 -0400 (EDT) Received: by mail-ed1-f52.google.com with SMTP id n17so1567137edt.13 for ; Mon, 11 Mar 2019 06:00:44 -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=F8Y+hGy/SHgxaEVcKwW4P/DgjaTEp4Rk+kHgNv8PhvU=; b=WTeCnCtKX++B1njzuy8zNtZmWyjIgUsV5jVCHe6NadNn/eyLAs6c3DFfmn0zL4sNl+ esowHQACdKelRllrXSpfP7Gt0Ds2NSlo6kHha38jjbqgoxGoSpgFHPQexYCsXH5PCkEG rrAPmUmnnIH67SiK1zix2uTxdks3ZmagS0O5HXjncCI68xOLaeE5KK0T13CaggI7MYhS yLT3nYwsg3I/8I6E8h93kbxFiR08wz0ME+C03+xXScwP0eUuMh6fpuvUFpcvqI3SqoNF Q38P39IkXkexbKkcCk6xIlHXBPT71GlWJfgEZbYudJbGOBzw4qyoeEvP2TFtN/RgdvD6 0UaQ== X-Gm-Message-State: APjAAAVy0a8JQC5/r7OBoO3hGtvCran/PgVu9j9Md0x6jzQhUcvlZ525 qncdfwah1Y5zQ2bHuOXi6Ew13Q== X-Google-Smtp-Source: APXvYqy1BP1bGe4IOdw3vXe+EoV47v2vD9vz18XMBnapvNVPDV59+crlk9/mqBYExj69cUrUWS8ndA== X-Received: by 2002:a17:906:1c4e:: with SMTP id l14mr13496923ejg.38.1552309243613; Mon, 11 Mar 2019 06:00:43 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id z23sm4681401edz.50.2019.03.11.06.00.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Mar 2019 06:00:42 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 4C423180454; Mon, 11 Mar 2019 14:00:42 +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: <1D3F7894-4A8F-4D57-BE27-18113FB14131@darbyshire-bryant.me.uk> 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 11 Mar 2019 14:00:42 +0100 Message-ID: <875zsp4lc5.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 13:00:44 -0000 Kevin Darbyshire-Bryant writes: >>> 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. > > 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. Yeah, but I didn't connect the dots for how this related to the CAKE use case until I saw your full example... >>> 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 can >> 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 p= reclude >>> 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 she= nanigans. That >>> of course makes you happier since cake doesn=E2=80=99t embed itself fur= ther >>> into conntrack. >>=20 >> Yeah, I definitely don't think CAKE has any business writing DSCP values >> into the mark. However, as I said before, there may be a case for adding > > I=E2=80=99m going forward on the basis that *cake* =E2=80=99storing DSCP = within > fwmark=E2=80=99 idea has died and will be trying to cobble something toge= ther > within act_connmark as that has a wider potential client base than > just cake. Yup, sounds good. 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... >> 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 figure >> out how the option should work. > > 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 p= oint > in working out the semantics of something that ultimately won=E2=80=99t be > accepted. 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. I think a possible way forward would be: 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. 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. 3. We submit whatever we come up with. If it gets accepted, great, otherwise we iterate based on feedback. Any objections? :) -Toke