On 09/23/14 at 06:32pm, Or Gerlitz wrote: > Indeed. > > The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as well > (NOT to offload OVS). > > We envision a seamless integration of user environment which is based on OVS > with SRIOV eSwitch and the grounds for that were very well supported in > Jiri’s V1.
Please consider comparing your model with what is described here [0]. I'm trying to write down an architecture document that we can finalize in Düsseldorf. [0] http://goo.gl/qkzW5y > The eSwitch hardware does not need to have multiple tables and ‘enjoys’ the > flat rule of OVS. The kernel datapath does not need to be aware of the > existence of HW nor its capabilities, it just pushes the flow also to the > switchdev which represents the eSwitch. I think you are saying that the kernel should not be required to make the offload decision which is fair. We definitely don't want to force the decision to be outside though, there are several legit reasons to support transparent offloads within the kernel as well outside of OVS. > Yep. LPC is the time and place to go over the multiple use-cases (phyiscal > switch, eSwitch, eBPF, etc) that could (should) be supported by the basic > framework. For reference: http://www.linuxplumbersconf.org/2014/ocw/proposals/2463 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
