On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: > On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar > <sridhar.samudr...@intel.com> wrote: >> On 4/12/2018 1:20 PM, Or Gerlitz wrote: >>> >>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar >>> <sridhar.samudr...@intel.com> wrote: >>>> >>>> On 11/12/2017 11:49 AM, Or Gerlitz wrote: >>>>> >>>>> Hi Dave and all, >>>>> >>>>> During and after the BoF on SRIOV switchdev mode, we came into a >>>>> consensus among the developers from four different HW vendors (CC >>>>> audience) that a correct thing to do would be to disallow any new >>>>> extensions to the legacy mode. >>>>> >>>>> The idea is to put focus on the new mode and not add new UAPIs and >>>>> kernel code which was turned to be a wrong design which does not allow >>>>> for properly offloading a kernel switching SW model to e-switch HW. >>>>> >>>>> We also had a good session the day after regarding alignment for the >>>>> representation model of the uplink (physical port) and PF/s. >>>>> >>>>> The VF representor netdevs exist for all drivers that support the new >>>>> mode but the representation for the uplink and PF wasn't the same for >>>>> all. The decision was to represent the uplink and PFs vports in the >>>>> same manner done for VFs, using rep netdevs. This alignment would >>>>> provide a more strict and clear view of the kernel model for e-switch >>>>> to users and upper layer control plane SW. >>>>> >>>> I don't see any changes in the Mellanox/other drivers to move to this new >>>> model to enable the uplink and PF port representors, any updates? >>> >>> Yeah, I am worked on that but didn't get to finalize the upstreaming >>> so far. I have resumed >>> the work and plan uplink rep in mlx5 to replace the PF being uplink rep >>> for 4.18 >>> >>>> It would be really nice to highlight the pros and cons of the old versus >>>> the >>>> new model. >>>> >>>> We are looking into adding switchdev support for our new 100Gb ice driver >>>> and could use some feedback on the direction we should be taking. >>> >>> good news. >>> >>> The uplink rep is clear cut that needs to be a rep device representing >>> the uplink just like vf >>> rep represents the vport toward the vf - please just do it correct >>> from the begining >>> >> Having an uplink rep will definitely help implement the slow path with >> flat/vlan network >> scenarios by not having to add PF to the bridge. >> >> But how do they help with a vxlan overlay scenario? In case of overlays, the >> slow path has to go via vxlan -> ip stack -> pf? > > in overlay networks scheme, the uplink has the VTEP ip and is not connected
the uplink rep has the vtep ip > to the bridge, e.g you use ovs you have vf reps and vxlan ports connected to > ovs > and the ip stack routes through the uplink rep > >> >> What about pf-rep? >>
