Re: [patch net-next RFC] tc: introduce OpenFlow classifier

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Jan 23, 2015 at 7:38 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>>If I understand skb_flow_dissect() correctly then you will always
>>fill of_flow_key with the inner most header. How would you for
>>example match on the outer UDP header?
>
> Yes, flow dissect is not ideal for this usage, for example also for the
> ipv6 addresses hashing. I was thinking about extending it. Eventually,
> this code can be merged with ovs as well.

if 'merging this with ovs' is the final goal then it's better
to do the other way around: extract ovs datapath and use it
as tc classifier.
Otherwise you'll essentially be repeating the same mistakes and
learning the same lessons as ovs guys did over years.
Especially considering the work we've been doing on ovs+bpf
it would be great to have common packet processing core
that is used by ovs and by tc.
ovs netlink interfaces will be all preserved and tc will gain
very capable datapath.
Obviously that is more involved than simply adding openflow-inspired
classifier, but imo it will be much more usable this way.