[Cake] act_connmark + dscp

[Kevin Darbyshire-Bryant]

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.

’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) 

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.

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.

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?

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


act_connmark_hack.patch
Description: act_connmark_hack.patch
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Using firewall connmarks as tin selectors

[Kevin Darbyshire-Bryant]

> On 4 Mar 2019, at 21:33, Toke Høiland-Jørgensen  wrote:

>> I think so too though I think the mechanism of copying the DSCP bits
>> and adding a ‘I did this’ 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?

If we don’t do that then potentially we have to look up the DSCP and update the 
conntrack mark for every packet.

>> I think cake ‘fwmark’ should have the smarts to look for the act_dscp
>> DSCP value if nothing else so we don’t have to have the overhead of
>> act_dscp set restoring DSCP to all the packets if we don’t want to.
> 
> Not sure what you mean here?

What I meant was that we can make the diffserv restore part optional.  Our 
qdisc (or whatever) could pick up the fw stored DSCP for tin/bandwidth 
selection and not require the real DSCP to be set and quite possibly 
washed/bleached again anyway.


>> I’m right at the limit of my coding ability with what I’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.
> 
> Happy to help you work out the details; but I think we'll make more
> progress on this if you are driving it :)

OK - we’ll see how long it takes before someone screams or laughs themselves to 
death :-)

Kevin
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake