From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (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 754A63B29E for ; Mon, 4 Mar 2019 16:42:32 -0500 (EST) Received: by mail-ed1-f67.google.com with SMTP id m12so5488766edv.4 for ; Mon, 04 Mar 2019 13:42:32 -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=XrEqjDST0VBBh4nETAmI/I7DMV76lh4ZZrwWzY9c0To=; b=OrwT8uYQmTGpX+e6FcfqzmDvvN1VWvLHQqP8doH9B6YSTdG0IhCDJ1QF6atC5Jr5Ty qwKLbOGetFBULALsqvB+7TPxWwKstRB2pfo3fGgSFQku4qC7kxueLy3IP7ofW3Ol2m6P o8kMzlnypjXarrN0gpJromqvLTCktFbwomnj8ciBxltec+/xRM2EHoTu/DxdABX9771K JAitlqXnKRJh5582W0I3S/wKOeG/ExB7faVoL6g5YN+bqTjoGgCc9AJEyYPTzkQ41EIg GwN58mxXCQoCRMh4j75BL77zu+X+d07fTu5gj9v6NpnJGEby+3HS/h4owtVv0U9tZjDW rvJA== X-Gm-Message-State: APjAAAWG/oimV4U8Sk3IrkwnNwixeLv0iAs/9mS5l6iuxMXaP8e0OhNf X2rsKWxIXBml1TuU1xSLzIKqio9XhnA= X-Google-Smtp-Source: APXvYqx9ldrX/+f8x4N4f5DzEacI68cKsnUcLvoiuzkeorwYk/80twVSqeVMmKyuhuU6TMoSbVlE+w== X-Received: by 2002:a17:906:4f15:: with SMTP id t21mr13966800eju.179.1551735751440; Mon, 04 Mar 2019 13:42:31 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id x34sm2423303edm.70.2019.03.04.13.42.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 13:42:30 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 7575A182E8E; Mon, 4 Mar 2019 22:42:30 +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: <87d0n62ukr.fsf@toke.dk> 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> <87lg1u35km.fsf@toke.dk> <87d0n62ukr.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 04 Mar 2019 22:42:30 +0100 Message-ID: <87a7ia2u61.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 21:42:32 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Kevin Darbyshire-Bryant writes: > >>> On 4 Mar 2019, at 17:36, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>> < snips > >>>=20 >>> Or act_dscp with 'get' and 'set' options :) >>>=20 >>>> As I said earlier I couldn't work out how m_conntrack did=E2=80=A6 any= thing at >>>> all to be honest! >>>=20 >>> act_connmark is pretty straight forward: >>> https://elixir.bootlin.com/linux/latest/source/net/sched/act_connmark.c= #L34 >> >> Oh bloody hell I=E2=80=99m an idiot - I was looking in user space tc cod= e for >> something that obviously lives in kernel land. Yes *now* I can see >> what it does. > > No comment ;) > >>>>>> @@ -1661,13 +1695,14 @@ static struct cake_tin_data *cake_select_tin= (struct 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 s= et >>>>> in it=E2=80=A6 >>>>=20 >>>> 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.= That also >>>> indicates to user space whether it should consider mangling packets or >>>> not e.g. >>>=20 >>> Ah, right. But that breaks the previous use case where someone just >>> wants to set fwmarks that get turned into CAKE tins? >> >> Yes, which is why I was hoping for upstream to bounce it, not least >> because of the unmasked use of fwmark field. Personally I=E2=80=99d li= ke to >> see that change reverted before we get trapped into something we=E2=80= =99ll >> regret. > > Well, we have plenty of time to try out things; the whole point of the > rc cycle is testing. But sure, if we don't settle on something, we can > just revert it :) And, well, the simple thing to do is just keep the current behaviour, or add a mask of 0xff, and use the tc action for everything that's more advanced than this... >>> 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=E2=80=A6 >> >> I think so too though I think the mechanism of copying the DSCP bits >> and adding a =E2=80=98I did this=E2=80=99 flag bit should be retained so= that other >> user space tools (iptables etc) can detect when a connmark based DSCP >> has been set/applied. > > I guess this could be an option as well? > >> I think cake =E2=80=98fwmark=E2=80=99 should have the smarts to look for= the act_dscp >> DSCP value if nothing else so we don=E2=80=99t have to have the overhead= of >> act_dscp set restoring DSCP to all the packets if we don=E2=80=99t want = to. > > Not sure what you mean here? > >> I=E2=80=99m right at the limit of my coding ability with what I=E2=80=99= ve sent in so >> far - the kernel space bits of act_connmark leave me mostly confused - >> really not sure where to start with act_dscp! > > I think I would start with `cp act_connmark.c act_dscp.c`, adding the > new file to the Makefile and Kconfig, and working from there. Then rip > out everything not needed, and copy over what you already added to > cake. Or even simpler, just add new options to act_connmark... -Toke