From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) (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 308043B29E for ; Mon, 4 Mar 2019 12:36:11 -0500 (EST) Received: by mail-ed1-f65.google.com with SMTP id 10so4923964eds.7 for ; Mon, 04 Mar 2019 09:36:11 -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=G147VhgoKNKWjx+DTWWecA66teeQaDFqnq9gNyZLCms=; b=ufb7gltAmtF8gZNz6/9FLFa/KRIY+q0xnMOSCdnoH6d+eNWqCVZcPiSkwbCw+GY5gZ 0fyVEHusYjptyW+ewakf76ee61PnQuegjVMBG/t/H07hSLcgiByE3dhBX35Igd2UrapG gCD4m63PgwE3c5mRLv/7zDSmjIpoxDVWzuCCVqkBiHB1TJHGRnkoxEBSm/ZSim8GWjk9 KnlVVsVUrgBB8FOb5Aq8wdYRtYIyTTRxqucxpTFMtz8jBGWdgvJOCxuN3HaBp2L3xL43 b/U83bTh8gCtpfVsvsikaIl50evH17kID0AAHL2w7CZl8ubi4GChMa82FrFaqfZ+Qiy7 SBow== X-Gm-Message-State: APjAAAXJojNUAoC5UwO9XqJiitfaX+73L57W+At2rOiFR8zZgGmIL+Pv 6DBknTcgmqj5MZ9klEcS/x5VpQ== X-Google-Smtp-Source: APXvYqwDc5fXX5RA5SroMh4lCu+n6qmoTemcAeHU9kD93hkEwubCy+DHOJwHWmIlxmJIexxVLB3dqQ== X-Received: by 2002:a17:906:b749:: with SMTP id fx9mr13619143ejb.239.1551720970239; Mon, 04 Mar 2019 09:36:10 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id e53sm2244008ede.26.2019.03.04.09.36.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 09:36:09 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 3F89A182E8E; Mon, 4 Mar 2019 18:36:09 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Kevin Darbyshire-Bryant Cc: Pete Heist , "cake\@lists.bufferbloat.net" In-Reply-To: <05095212-7204-4490-97DF-8A7A39B6584C@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> <4D01FA8A-E732-49C8-A4E6-8EA453CFA80C@heistp.net> <87d0n6lwgw.fsf@toke.dk> <52F1A35A-9F57-40EC-AF9B-EC6D8BD376BE@darbyshire-bryant.me.uk> <871s3mlsge.fsf@toke.dk> <87r2bm386k.fsf@toke.dk> <05095212-7204-4490-97DF-8A7A39B6584C@darbyshire-bryant.me.uk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 04 Mar 2019 18:36:09 +0100 Message-ID: <87lg1u35km.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 17:36:11 -0000 Kevin Darbyshire-Bryant writes: >> On 4 Mar 2019, at 16:39, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Kevin Darbyshire-Bryant writes: >>=20 >> [ ... snipping a bit of context here ... ] >>=20 >>>>>>> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp) >>>>>>> +{ >>>>>>> + enum ip_conntrack_info ctinfo; >>>>>>> + struct nf_conn *ct; >>>>>>> + >>>>>>> + ct =3D nf_ct_get(skb, &ctinfo); >>>>>>> + if (!ct) >>>>>>> + return; >>>>>>> + >>>>>>> + ct->mark &=3D 0x80ffffff; >>>>>>> + ct->mark |=3D (0x40 | dscp) << 24; >>>>>>=20 >>>>>> Right, so we *might* have an argument that putting the *tin* into the >>>>>> fwmark is CAKE's business, but copying over the dscp mark is not >>>>>> something a qdisc should be doing=E2=80=A6 >>>>>=20 >>>>> Why ever not? It=E2=80=99s not the DSCP, it=E2=80=99s a lookup value= into the cake >>>>> priority table, it just happens to look like the DSCP ;-) >>>>=20 >>>> If it quacks like a duck=E2=80=A6 >>>=20 >>> I honestly don=E2=80=99t know where to go from here. I=E2=80=99m clearl= y trying to do >>> something that the kernel doesn=E2=80=99t want to do. >>=20 >> I'm not disputing that what you're trying to do (moving DSCP field into >> connmark) is useful. I'm just questioning whether CAKE is the right >> place to do this. I think it would fit better in a TC action; either >> modify act_connmark, or create a new action to sync fwmarks and DSCP >> marks=E2=80=A6 > > Interesting. Thinks out loud - Two actions - =E2=80=98act_storedscp=E2= =80=99, > =E2=80=98act_restoredscp' Or act_dscp with 'get' and 'set' options :) > As I said earlier I couldn't work out how m_conntrack did=E2=80=A6 anythi= ng at > all to be honest! act_connmark is pretty straight forward: https://elixir.bootlin.com/linux/latest/source/net/sched/act_connmark.c#L34 >>> @@ -1661,13 +1695,14 @@ static struct cake_tin_data *cake_select_tin(st= ruct Qdisc *sch, >>> tin =3D 0; >>>=20 >>> else if (q->rate_flags & CAKE_FLAG_FWMARK && /* use fw mark */ >>> - skb->mark && >>> - skb->mark <=3D q->tin_cnt) >>> - tin =3D q->tin_order[skb->mark - 1]; >>> - >>> - else if (TC_H_MAJ(skb->priority) =3D=3D sch->handle && >>> - TC_H_MIN(skb->priority) > 0 && >>> - TC_H_MIN(skb->priority) <=3D q->tin_cnt) >>> + skb->mark & 0x40000000) { >>=20 >> I think there's something odd with this mask? There's only one bit set >> in it=E2=80=A6 > > I use the single bit as a flag to indicate cake has stored the DSCP > in the lower 6 bits of the byte. Otherwise with a DSCP of 0 (the > default) it=E2=80=99s rather difficult to know if a connection has been > through the cake =E2=80=99save dscp to fwmark=E2=80=99 process or not. T= hat also > indicates to user space whether it should consider mangling packets or > not e.g. Ah, right. But that breaks the previous use case where someone just wants to set fwmarks that get turned into CAKE tins? I think this definitely is leaning towards decoupling the fw-mark-to-DSCP settings to an action. And probably making the shift and mask configurable rather than hard-coding something... -Toke