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 I can spare
