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]

Message-ID: <CAJ3xEMjqj5ENO8NRbcYFFCcS4NGwrNbYo8uydHEYMyXHjCBqhw@mail.gmail.com>
Date:   Fri, 13 Apr 2018 11:57:11 +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 Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> 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

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?
>>