Re: [PATCH] Add tcindex to conntrack and add netfilter target/matches

[Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz>]

On 12/07/2015 11:45 AM, Florian Westphal wrote:
> Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz> wrote:
>> Hi All,
>>
>> I'm still hoping for some feedback on this.  I have some userspace
>> patches around this as well, (to set/show the tc_index in the
>> connection, and to add the marking/matching rules in iptables), but I am
>> holding off on sending them until I know what people think of this
>> idea/implementation first.
> I can't say for sure since I don't know enough about tc.
>
> However, AFAICS tc_index seems to be something that should be internal
> to tc and not exposed/changeable via iptables.
tc_index is a mark that can be set by certain configurable ingress 
schedulers (dsmark, GRED, ingress) for later classification via the 
tcindex classifer.  This just adds an alternative mechanism for setting 
this mark if those schedulers aren't being used.
* dsmark sets the tc_index value based on the incoming DSCP value
* ingress sets the tc_index value based on other rules (e.g. mark set 
via iptables)
* New code sets tc_index directly based on iptables classification or 
restoring saved value.
>
>> Basically it allows 16 bits of marking in skb and connmark for traffic
>> control purposes using an existing field in the skb.
> Why not extend cls_flow to allow matching ctmark directly via tc
> filters instead of requiring conntrack->foo copy to skb->foo?
The flow classifier doesn't have support for masks on the mark (or other 
fields), so doesn't provide enough control to differentiate between 
outgoing/incoming traffic.  Also, do all packets have an associated 
connection? if we restore the connection mark to the packet mark with a 
mask, then tc will only see the marking that we want it to see, and 
packets that don't have an associated connection will be matched to 
other rules.  Also, the tc_index and fw filters already exist for the 
skb fields.
>
> We also have -j CLASSIFY to set skb->priority and at least cls_flow
> seems to be able to match on that (did not test it).
The functionality we are trying to achieve (for performance reasons) is 
as follows:
1st packet in flow in each direction (slow path):
- Go through list of classification rules and set something (packet 
class) in a connection mark (with a mask) for traffic on this flow in 
this direction.
Other packets in flow in this direction (fast path):
- Restore the part of the mark for this direction from connection and go 
to egress where tc rules can do correct traffic control based on the 
restored mark.

I think that CLASSIFY can only really go through the slow path.

We also want to make use of hierarchical qdiscs, which requires that the 
packet steps through levels of qdiscs, being filtered/classified to the 
correct class at each level, which I think means that priority field 
isn't appropriate, as it might change at different steps.