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  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 17 Sep 2014 15:07:27 -0700
From:	Jesse Gross <>
To:	Jiri Pirko <>
Cc:	Pravin Shelar <>,
	netdev <>,
	David Miller <>,
	nhorman <>,
	Andy Gospodarek <>,
	Thomas Graf <>,
	Daniel Borkmann <>,
	Or Gerlitz <>,
	Andy Zhou <>,
	Ben Hutchings <>,
	Stephen Hemminger <>,
	"jeffrey.t.kirsher" <>,
	vyasevic <>,
	Cong Wang <>,
	"john.r.fastabend" <>,
	Eric Dumazet <>,
	Jamal Hadi Salim <>,
	sfeldma <>,
	Florian Fainelli <>,
	roopa <>,
	John Linville <>,
	"" <>,
	jasowang <>, ebiederm <>,
	Nicolas Dichtel <>,
	"ryazanov.s.a" <>,
	buytenh <>, aviadr <>,
	nbd <>,
	Alexei Starovoitov <>,
	Neil Jerram <>,
	Rony Efraim <>
Subject: Re: [patch net-next 01/13] openvswitch: split flow structures into
 ovs specific and generic ones

On Wed, Sep 17, 2014 at 1:34 AM, Jiri Pirko <> wrote:
> Thu, Sep 04, 2014 at 10:46:28PM CEST, wrote:
>>On the other hand if vswitchd uses common interface (switchdev) there
>>is no need to extend ovs kernel interface. For example specifying
>>extra metadata, like (sw only, hw olny, both).
> I understand you point of view. However from the offloading perspective
> it makes much more sense to push the flows through a single interface
> (ovs genl) and only offload selected flows to hw (pushing further).
> Having vswitchd to handle 2 different ifaces for the same/similar thing
> does not seem like a clean solution to me. And it really breaks the
> offloading view.
> Plus the amount of code needed to be pushed into ovs kernel dp code in
> order to enable this is small.

This is missing the point: software forwarding and a hardware driver
interface are doing totally different things. Over time, these will
diverge and you will essentially up with two separate paths packed
together which doesn't help anything. This is not a theoretical
concern as different directions either already exist or have been
proposed. On the software side, there is the BPF proposal which is not
likely to map to hardware any time soon. On the other hand, hardware
is usually composed of multiple tables/functions with varying
capabilities. Sooner or later you will want to take advantage of these
and doing so isn't really possible with the software optimized flows
that the kernel handles. At that point, you will likely introduce a
new interface to userspace to expose this and get flows processed in a
different 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