Re: SRIOV switchdev mode BoF minutes

["Samudrala, Sridhar" <sridhar.samudrala@intel.com>]

On 4/12/2018 1:20 PM, Or Gerlitz wrote:
> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
> <sridhar.samudrala@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?

What about pf-rep?