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@xxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
