[Cake] Using firewall connmarks as tin selectors

[Kevin Darbyshire-Bryant]

> On 27 Feb 2019, at 15:14, Toke Høiland-Jørgensen <toke at redhat.com> wrote:
> 
> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
> 
>> How unpopular would the idea of having cake look at skb->mark directly be?
>> 
>> https://github.com/ldir-EDB0/sch_cake/commit/64d0e6ac9368a271221db888ab91a367fcd37ae1
>> 
>> https://github.com/ldir-EDB0/tc-adv/commit/4f16ae5d588d44f8a5c83fe2f2b7dcad97843cbc
> 

Hiya Toke,

OK, so it’s not an instant no :-)

> Hmm, not impossible, but seeing as we already have a way to achieve that
> with BPF, is it really needed?

Well, from a command line usability I’d say a ’no/fwmark’ option is a lot easier to grasp/configure than invoking anything BPF related.

Similarly, a suitable BPF program requires building and based on your below comments, with hard coded constants e.g. major number.  The ‘entry barrier’ is high, I have to write the BPF program, compile it (eBPF ‘toolchain'), maintain it, install it and there are certain (lack of) features that make it clunky to use even after you’ve done all that.

> 
>> I did the equivalent in eBPF here
>> https://github.com/ldir-EDB0/cls_bpf_connmark_to_caketin but I can’t
>> work out how to make the major number a tc command line argument into
>> the BPF code.
> 
> You can't, but you can set the major number explicitly when you create
> the qdisc:

Indeed the script I’m using does exactly that, but it means I need a ‘hard coded’ BPF program (or section at least) per cake instance.  Tail wagging the dog springs to mind.

I re-worked the code (again) anyway, (last commit https://github.com/ldir-EDB0/sch_cake/commits/mine )

The driver for doing any of this is primarily related to wan ingress classification.  DSCP can’t be trusted and can’t be manipulated (save for eBPF)  Neither iptables rules nor conntrack NAT lookup will have occurred so an eBPF program using internal addresses is challenging.  i *can* persuade tc to restore the connmark on ingress, so I can write old style, complicated, slow iptables rules to apply a connmark once on egress and have that connmark used for both egress & ingress aspects of that connection.

I also equally aware that this is ‘creeping featuritis’ and doing nothing to speed cake up…actually I may have improved BESTEFFORT a little - we no longer look for matching TC Major numbers if there’s no actual choice of tin to be made :-)


Cheers,

Kevin D-B

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