netdev - Re: SRIOV switchdev mode BoF minutes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Apr 2018 11:56:43 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc:     David Miller <davem@...emloft.net>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Andy Gospodarek <gospo@...adcom.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: SRIOV switchdev mode BoF minutes

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