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:   Tue, 14 Nov 2017 15:32:49 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Or Gerlitz <gerlitz.or@...il.com>,
        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>,
        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 Tue, 14 Nov 2017 12:00:32 -0800, Alexander Duyck wrote:
> On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
> > On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck wrote:  
> >> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:  
> > Lets focus on this point for a moment before discussing the other points
> > you raised.
>
> When SR-IOV was introduced there were two available modes, Virtual
> Ethernet Port Aggregation, aka VEPA, and Virtual Ethernet Bridging,
> aka VEB. The fact is SwitchDev is designed specifically for networking
> SR-IOV with Virtual Ethernet Bridging, aka VEB. You argue that the
> legacy model is bad, but I would argue that is because the legacy
> model was really designed to work more for both VEPA than with VEB,
> whereas SwitchDev only focuses on VEB. If you take a look in the ixgbe
> or i40e drivers you will see that we support configuring both of those
> modes via ndo_bridge_setlink since we have customer install bases that
> actually prefer VEPA over VEB as they prefer to have their traffic
> centrally managed instead of having the local host managing the
> traffic. We cannot just arbitrarily tell our customers they are doing
> SR-IOV using the "wrong model".

Maybe that's an obvious statement, but the perhaps real problem we are
grappling with here is that VEPA doesn't really exist as forwarding
model outside of SR-IOV NICs.  So we have no software construct that
cleanly maps onto it for offload.

> I would rather not have SwitchDev become the next SystemD. The type
> argument you are making is basically dictating to us and our customers
> how things are supposed to work based on your view things. We have
> different hardware, different customers, and all of our needs aren't
> necessarily met by SwitchDev. I would agree that SwitchDev is the
> go-to solution for VEB configuration, and we do plan to have future
> hardware support it. In addition I would argue that for the sake of
> consistency we should make sure that any feature that gets added to
> the legacy has to be supported by the SwitchDev model as well before
> it could be supported. If anything my hope is to evolve the legacy
> model to have much of the same look and feel as SwitchDev, but that
> will take time and require changes to the legacy model.

To me the whole point of switchdev is to reuse existing ABIs, TC, FDB,
bridging etc.  We are arguing to stop adding special SR-IOV features,
if the general direction of things is to just reflect configuration
done with SW ABIs to the hardware.  I think saying we need feature
parity between the models is missing this crucial point.

Also more ways there are to configure a single thing, the more confusing
it will be to the users.