lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Jan 2015 09:43:13 -0800
From:	Alexei Starovoitov <>
To:	Jiri Pirko <>
Cc:	Thomas Graf <>,
	"" <>,
	"David S. Miller" <>,
	Jamal Hadi Salim <>
Subject: Re: [patch net-next RFC] tc: introduce OpenFlow classifier

On Fri, Jan 23, 2015 at 7:38 AM, Jiri Pirko <> 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.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists