From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail33c50.megamailservers.eu (mail224c50.megamailservers.eu [91.136.10.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8301E3CB35 for ; Wed, 6 Mar 2019 11:47:27 -0500 (EST) X-Authenticated-User: sagermail@sager.me.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1551890846; bh=0F2hAmIGuSMz6PX79jXx+EWNt8QDTPuoxTYFx83513s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M1EiOz9eeiw8Stxq5wdtv9AUwJ883OLsbs7sE91hIyvG80/FFPEiuDbwu1703r5wS hrchDX0wGc3n79PFpSWwiTdmprn/z/8seIeiwMEWrptyBIOnezfaV/wGgkjVQaCU4A qywvKfr9g0esWct5hKHzpBI8AQxpi9UnLjacoDqk= Feedback-ID: john@sager.me.u Received: from mainserver.wc (97.83.2.81.in-addr.arpa [81.2.83.97]) (authenticated bits=0) by mail33c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x26GlOPS005941 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 6 Mar 2019 16:47:26 +0000 Received: from [2001:8b0:cbe3:0:6236:ddff:fee9:e4ea] by mainserver.wc with esmtp (Exim 4.86_2) (envelope-from ) id 1h1ZhU-00088X-6T for cake@lists.bufferbloat.net; Wed, 06 Mar 2019 16:47:24 +0000 To: cake@lists.bufferbloat.net References: <875zsw110r.fsf@toke.dk> From: John Sager Openpgp: preference=signencrypt Message-ID: <2addb109-0cc4-cdb9-886d-d86da9b5bf51@sager.me.uk> Date: Wed, 6 Mar 2019 16:47:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <875zsw110r.fsf@toke.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-CTCH-RefID: str=0001.0A0B020A.5C7FF99E.0013, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=fZaDNXYF c=1 sm=1 tr=0 a=dws6IJh5fU+Ftmrx3Eq8JA==:117 a=dws6IJh5fU+Ftmrx3Eq8JA==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=NTGMnVQrEZIA:10 a=SxEtWCb9AAAA:8 a=kurRqvosAAAA:8 a=3d6gZOCh1W4sKXniodsA:9 a=QEXdDO2ut3YA:10 a=nmmqd-WjEVsm9Gjy6SiX:22 a=kbxRQ_lfPIoQnHsAj2-A:22 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: Wed, 06 Mar 2019 16:47:27 -0000 You should be able to infer get (egress action) and set (ingress action) from which qdisc it is attached to. Is it possible to do that when the action function is invoked (from parameters of tcf_connmark_act() or does it need a static flag set when tc attaches the action? In act_conntrack.c there is another case further down where ct->mark is copied to skb->mark so you need to cover both cases (inline function?). John On 06/03/2019 15:21, Toke Høiland-Jørgensen wrote: > Kevin Darbyshire-Bryant writes: > >> Before I go too far down this road (and to avoid the horror of >> actually trying to code it) here’s what I’m trying to achieve. >> >> >> act_connmark + dscp is designed to copy a DSCP code to/from conntrack mark. It uses 8 bits of the mark field, currently the most significant byte. >> >> Bits 31-26: DSCP >> Bit 25: Spare/Future >> Bit 24: Valid DSCP set >> >> The valid bit is set when the ‘getdscp’ function has written a DSCP >> value into the conntrack (& hence skb) mark. This allows us & other >> skb->mark/ct->mark applications (eg iptables, cake qdisc) to know that >> a DSCP value has been placed in the field. We cannot simply use a >> non-zero DSCP because zero is a valid DSCP. > > If someone installs the action, the field is supposedly always copied; > so why do we need another flag? > > Instead, I'd suggest adding user options with mask and shift to make it > possible to configure where in the mark field the values are stored... > >> ’setdscp’ restores the DSCP field from the stored DSCP if valid bit is set. >> >> >> Modes: >> >> getdscp - If ct->mark doesn’t contain a valid DSCP, copy the DSCP >> field from the current skb (if valid for that skb ie. ip4/ip6) and set >> the valid bit. >> >> bleach/aka wash - As part of the getdscp routine, optionally null out >> the DSCP bits. We need a bleach routine because we need to see the >> DSCP bits intact so we can copy them to the mark. If cake washes them >> then we don’t get to see them, defeating the entire point. >> >> setdscp - if skb->mark valid bit set, copy the skb->mark stored DSCP >> to the diffserv bits of the current skb (if appropriate) > > TC actions are executed before the qdisc, so I don't think bleach/wash > is really needed? Also, it can already be achieved with the pedit > action. So I think 'get' and 'set' are enough. > >> I’ve attached a *VERY* rough starting point for how far I’ve got - not >> even compiled yet… I doubt it does. Not a natural (kernel) programmer >> so everything is a struggle. >> >> Two things I’m falling over: >> >> 1) Really not sure how to get parameters in to set the >> ‘getdscp/setdscp/wash’ options. > > You'll need to add new netlink parameter values and parse them like we > do in cake (after the existing struct-copy-based option passing). I > think a single option that can be set to *either* "get" *or* "set" will > be simpler, then you don't have to worry about what happens if someone > enables both. > >> 2) Is it possible to have different tc actions on an interface and a >> mirred fed ifb interface? That could be a real killer actually. We >> need to do different things on egress vs ingress. > > Yes, you can chain actions, and they are per-interface. > >> 3) (Spanish Inquisition moment) The original connmark code goes and >> does a nf_ct_get_tuplepr if the nf_ct_get fails. Why would the >> nf_ct_get fail? > > Presumably because nf_ct_get just reads a field in the skb; which may > not have been set yet in some cases, necessitating a full lookup. > > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >