On Wed, Sep 17, 2014 at 1:34 AM, Jiri Pirko <j...@resnulli.us> wrote: > Thu, Sep 04, 2014 at 10:46:28PM CEST, pshe...@nicira.com 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
