On Wed, Sep 24, 2014 at 4:32 PM, Thomas Graf <tg...@suug.ch> wrote: > 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
Yep, this can serve us for the architecture discussion @ LPC. Re the SRIOV case, you referred to the case where guest VF traffic goes through HW (say) VXLAN encap/decap -- just to make sure, we need also to support the simpler case, where guest traffic just goes through vlan tag/strip. >> 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 The SRIOV case is only mentioned here in the "Compatibility with existing FDB ioctls for SR-IOV" bullet, so I'm a bit nervous... we need to have it clear in the agenda. Also, this BoF needs to be double-len, two hours, can you act to get that done? thanks, Or. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
