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

[Daniel Borkmann <daniel@iogearbox.net>]

On 12/14/2015 12:00 AM, Luuk Paulussen wrote:
> On 12/09/2015 10:07 PM, Daniel Borkmann wrote:
>> On 12/07/2015 03:19 AM, Luuk Paulussen wrote:
>>> 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.
>>
>> Fwiw, tc_index can be read/written by cls_bpf (and you can also apply
>> masks
>> on that field if needed).
> I've just been looking into this and it does seem like it might cover a
> small part of what we are trying to do, although misses the key part,
> which is to use connection tracking information to limit full processing
> to the first packet of a flow in each direction. I'm guessing that there
> isn't any bpf support for connection information?

Depends on your requirements, but you could probably implement a minimal
tracker in cls_bpf through eBPF itself. Or alternatively, add a helper
function to retrieve the cttuple? Florian mentioned cls_flow already, so
you could orientate yourself there wrt developing an eBPF helper.

> One thing that isn't quite clear to me. Is it possible to use xt_bfp.c
> to set the tc_index field from netfilter?  If this is the case, then it
> does set a precedent
> for being able to set this value outside of tc code (but sill misses the
> save/restore possibility).

xt_bpf covers only classic BPF, so it's unfortunately not possible to
match or set tc_index from there.

> Given that tc_index is simple metadata I'm guessing that filter
> performance over the tcindex classifier wouldn't be significantly better?

I think it depends on how you encode your information, f.e. if you can get
away w/o an index to classid mapping through a hash table, etc. Maybe best
to give it a try on benchmarking.

Cheers,
Daniel