[Cake] Using firewall connmarks as tin selectors

Toke Høiland-Jørgensen toke at redhat.com
Mon Mar 4 12:36:09 EST 2019


Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:

>> On 4 Mar 2019, at 16:39, Toke Høiland-Jørgensen <toke at redhat.com> wrote:
>> 
>> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
>> 
>> [ ... snipping a bit of context here ... ]
>> 
>>>>>>> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp)
>>>>>>> +{
>>>>>>> +	enum ip_conntrack_info ctinfo;
>>>>>>> +	struct nf_conn *ct;
>>>>>>> +
>>>>>>> +	ct = nf_ct_get(skb, &ctinfo);
>>>>>>> +	if (!ct)
>>>>>>> +		return;
>>>>>>> +
>>>>>>> +	ct->mark &= 0x80ffffff;
>>>>>>> +	ct->mark |= (0x40 | dscp) << 24;
>>>>>> 
>>>>>> 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…
>>>>> 
>>>>> Why ever not?  It’s not the DSCP, it’s a lookup value into the cake
>>>>> priority table, it just happens to look like the DSCP ;-)
>>>> 
>>>> If it quacks like a duck…
>>> 
>>> I honestly don’t know where to go from here. I’m clearly trying to do
>>> something that the kernel doesn’t want to do.
>> 
>> 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…
>
> Interesting.  Thinks out loud - Two actions - ‘act_storedscp’,
> ‘act_restoredscp'

Or act_dscp with 'get' and 'set' options :)

> As I said earlier I couldn't work out how m_conntrack did… anything 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(struct Qdisc *sch,
>>> 		tin = 0;
>>> 
>>> 	else if (q->rate_flags & CAKE_FLAG_FWMARK && /* use fw mark */
>>> -		 skb->mark &&
>>> -		 skb->mark <= q->tin_cnt)
>>> -		tin = q->tin_order[skb->mark - 1];
>>> -
>>> -	else if (TC_H_MAJ(skb->priority) == sch->handle &&
>>> -		 TC_H_MIN(skb->priority) > 0 &&
>>> -		 TC_H_MIN(skb->priority) <= q->tin_cnt)
>>> +		   skb->mark & 0x40000000) {
>> 
>> I think there's something odd with this mask?  There's only one bit set
>> in it…
>
> 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’s rather difficult to know if a connection has been
> through the cake ’save dscp to fwmark’ process or not.  That 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


More information about the Cake mailing list