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 20:02:21 -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 19:04:36 -0800, Alexander Duyck wrote:
> On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
> <jakub.kicinski@...ronome.com> wrote:
> > On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:  
> >> >> We basically need to do some feasability research to see if we can
> >> >> actually meet all the requirements for switchdev on i40e. We have been
> >> >> getting mixed messages where we are given a great many "yes, but" type
> >> >> answers. For i40e we are looking into it but I don't have high
> >> >> confidence in our ability to actually support it in hardare/firmware.
> >> >> If it were as easy as you have been led to believe, we would have done
> >> >> it months ago when we were researching the requirements to support switchdev  
> >> >
> >> > wait, Sridhar made seven rounds of his submission (this is the v7
> >> > pointer [1]) and you
> >> > still don't know if what you were attempting to push upstream can
> >> > work, something is
> >> > weird here, can you clarify? Jeff?  
> >>
> >> Not weird so much as stubborn. The patches were being pushed based on
> >> the assumption that the community would accept a NIC generating port
> >> representors that didn't necessarily pass traffic, and then even when
> >> we had them passing traffic the PF still wasn't configured to handle
> >> being the default destination for traffic without any rules
> >> associated, instead VFs would directly send to the outside world.  
> >
> > Perhaps the way forward is to lift the requirement on passing traffic,
> > as long as the limitation is clearly expressed to the users.  
> 
> No, I am not arguing for that because then SwitchDev will fall into
> disarray. If we want to have a strict definition for what is SwitchDev
> and what isn't I am okay with that. It gives us a definition of what
> our hardware needs to do in order to support it and without that we
> are going to get hardware that just bends the rules to claim support
> for it.

Let me make sure we understand each other.  The switchdev SR-IOV mode is
what happens when user requests DEVLINK_ESWITCH_MODE_SWITCHDEV.  Are you
saying you are opposed to adding DEVLINK_ESWITCH_MODE_VEPA?

> All I am asking for is for us to not close the door to the possibility
> of adding features to legacy SR-IOV. I am hoping to use a source
> macvlan based approach to make it so that we can support "port
> representors" for devices that can't support full SwitchDev. The idea
> would be to use them to get as close to SwitchDev level support on
> legacy devices as possible without using full SwitchDev. That should
> solve a good part of the issue, but I am pretty certain I need to be
> able to extend legacy SR-IOV in order to support it. I had talked with
> Jiri at netdev 2.1 about it back when we had submitted the v7 patches,
> and the decision was to look at doing "port representors" but don't
> associate them with SwitchDev. I was out on Sabbatical for most of the
> summer and I am just now starting on the macvlan work I had planned. I
> hope to have it done before the next netdev and then we can discuss it
> there if it needs more discussion than what we can have on the mailing
> list.

I don't know what you mean with the macvlan based approach.  Could you
perhaps describe it in more detail?  Will it allow users to configure
forwarding and queueing with existing, standard tools and APIs?

> I'm fine with us placing any legacy SR-IOV changes under more
> scrutiny. I am just not open to saying we will not extend or update
> any features for legacy SR-IOV. The fact is we are still selling a ton
> of ixgbe based parts, so I can't say with any certainty that there
> won't be a request for some new SR-IOV feature in the future.
> 
> - Alex