netdev - Re: [PATCH net-next v2 0/3] VGT+ support

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, 5 Nov 2019 01:38:08 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
CC:     "sbrivio@...hat.com" <sbrivio@...hat.com>,
        "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        "sd@...asysnail.net" <sd@...asysnail.net>,
        Jiri Pirko <jiri@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        Ariel Levkovich <lariel@...lanox.com>
Subject: Re: [PATCH net-next v2 0/3] VGT+ support

On Fri, 2019-11-01 at 17:21 -0700, Jakub Kicinski wrote:
> On Fri, 1 Nov 2019 21:28:22 +0000, Saeed Mahameed wrote:
> > Jakub, since Ariel is still working on his upstream mailing list
> > skills
> > :), i would like to emphasis and summarize his point in text style
> > ;-)
> > the way we like it.
> 
> Thanks :)
> 
> > Bottom line, we tried to push this feature a couple of years ago,
> > and
> > due to some internal issues this submission ignored for a while,
> > now as
> > the legacy sriov customers are moving towards upstream, which is
> > for me
> > a great progress I think this feature worth the shot, also as Ariel
> > pointed out, VF vlan filter is really a gap that should be closed.
> > 
> > For all other features it is true that the user must consider
> > moving to
> > witchdev mode or find a another community for support.
> > 
> > Our policy is still strong regarding obsoleting legacy mode and
> > pushing
> > all new feature to switchdev mode, but looking at the facts here  I
> > do
> > think there is a point here and ROI to close this gap in legacy
> > mode.
> > 
> > I hope this all make sense. 
> 
> I understand and sympathize, you know full well the benefits of
> working
> upstream-first...
> 
> I won't reiterate the entire response from my previous email, but the
> bottom line for me is that we haven't added a single legacy VF NDO
> since 2016, I was hoping we never will add more and I was trying to
> stop anyone who tried.
> 

The NDO is not the problem here, we can perfectly extend the current
set_vf_vlan_ndo to achieve the same goal with minimal or even NO kernel
changes, but first you have to look at this from my angel, i have been
doing lots of research and there are many points for why this should be
added to legacy mode:

1) Switchdev mode can't replace legacy mode with a press of a button,
many missing pieces.

2) Upstream Legacy SRIOV is incomplete since it goes together with
flexible vf vlan configuration, most of mlx5 legacy sriov users are
using customized kernels and external drivers, since upstream is
lacking this one basic vlan filtering feature, and many users decline
switching to upstream kernel due to this missing features.

3) Many other vendors have this feature in customized drivers/kernels,
and many vendors/drivers don't even support switchdev mode (mlx4 for
example), we can't just tell the users of such device we are not
supporting basic sriov legacy mode features in upstream kernel.

4) the motivation for this is to slowly move sriov users to upstream
and eventually to switchdev mode.

This has been a large gap and disadvantage in upstream and 
this feature has been long time coming and we have been laying the
grounds for it since 2016 (IFLA_VF_VLAN_LIST), it is not reasonable
that we have APIs to set all kinds of vf vlan attributes but not vlan
filters, I really believe this feature should be IN.

I still believe in the switchdev only policy, but vlan filter is a gray
area, Legacy sriov is all about VF vlans.

my opinion is: VF Vlan filter  is a very basic requirement for SRIOV,
not all HW support switchdev mode and many customers and usecases are
meant to use legacy mode only, it is unfair to block this feature, and
this is a great loss of users and use cases to the upstream kernel.

Now if the only remaining problem is the uAPI, we can minimize kernel
impact or even make no kernel changes at all, only ip route2 and
drivers, by reusing the current set_vf_vlan_ndo.