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:   Sun, 12 Nov 2017 12:38:32 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Or Gerlitz <gerlitz.or@...il.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 Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz <gerlitz.or@...il.com> 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.

I would have to disagree with this. For devices such as 82599 that
doesn't have a true switch this may limit future functionality since
we can't move it over to switchdev mode. For example one thing I may
need to add is the ability to disable multicast and broadcast receive
on a per-VF basis at some point in the future.

You may not recall but we tried to transition the i40e driver over to
SwitchDev, the parts supported by i40e have a much more robust l2
forwarding framework than the 82599, and the result was we were told
that while we might look at doing port representors some other way,
there was no way we could use switchdev since the hardware couldn't
support the requirements of switchdev in terms of default routes and
forwarding behavior. I am planning to resolve the port representor
issue by looking at coming up with something like a "source mode"
macvlan based port representor. I figure that is probably the closest
match for what the Intel hardware does since really the VFs are
nothing more than a physical macvlan interface in and of themselves as
the hardware doesn't have a full switch.

> 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.
>
> Or.

This part sounds fine.

- Alex