Date:   Fri, 1 Nov 2019 21:28:22 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     Ariel Levkovich <lariel@...lanox.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
CC:     "dsahern@...il.com" <dsahern@...il.com>,
        "sbrivio@...hat.com" <sbrivio@...hat.com>,
        "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sd@...asysnail.net" <sd@...asysnail.net>,
        Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net-next v2 0/3] VGT+ support

On Fri, 2019-11-01 at 19:44 +0000, Ariel Levkovich wrote:
> On 10/31/19 8:23 PM, Jakub Kicinski <jakub.kicinski@...ronome.com>
> wrote:
> > On Thu, 31 Oct 2019 19:47:25 +0000, Ariel Levkovich wrote:
> > > The following series introduces VGT+ support for SRIOV vf
> > > devices.
> > > 
> > > VGT+ is an extention of the VGT (Virtual Guest Tagging)
> > > where the guest is in charge of vlan tagging the packets
> > > only with VGT+ the admin can limit the allowed vlan ids
> > > the guest can use to a specific vlan trunk list.
> > > 
> > > The patches introduce the API for admin users to set and
> > > query these vlan trunk lists on the vfs using netlink
> > > commands.
> > > 
> > > changes from v1 to v2:
> > > - Fixed indentation of RTEXT_FILTER_SKIP_STATS.
> > > - Changed vf_ext param to bool.
> > > - Check if VF num exceeds the opened VFs range and return without
> > > adding the vfinfo.
> > 
> > If you repost something without addressing feedback you received
> > you
> > _have_ _to_ describe what that feedback was and why it was ignored
> > in 
> > the cover letter of the new posting, please and thank you.
> 
> Right, I must've missed that.
> 
> I re posted the patches to address the code related feedback from
> Stephen while
> 
> we continue the discussion on the concept of legacy mode features.
> 
> On 10/30/19 you wrote:
> 
>     "
> 
>     The "we don't want any more legacy VF ndos" policy which I think
> we
>     wanted to follow is much easier to stick to than "we don't want
> any
>     more legacy VF ndos, unless..".
>    
>     There's nothing here that can't be done in switchdev mode
> (perhaps
>     bridge offload would actually be more suitable than just flower),
>     and the uAPI extension is not an insignificant one.
>    
>     I don't think we should be growing both legacy and switchdev
> APIs, at
>     some point we got to pick one. The switchdev extension to set
> hwaddr
>     for which patches were posted recently had been implemented
> through
>     legacy API a while ago (by Chelsio IIRC) so it's not that we're
> looking
>     towards switchdev where legacy API is impossible to extend. It's
> purely
>     a policy decision to pick one and deprecate the other.
>    
>     Only if we freeze the legacy API completely will the
> orchestration
>     layers have an incentive to support switchdev. And we can save
> the few
>     hundred lines of code per feature in every driver..
>     "
> 
> 
> Unfortunately, like Saeed and yourself mentioned, we still face
> customers that are
> 
> refusing to move to switchdev while requiring feature and
> capabilities
> 
> in virtual environments.
> 
> 
> 
> We have several configurations available today for legacy that
> include vlan settings
> for the VF.
> I know that we decided to refrain from adding new legacy ndos but I
> also think we
> left a gap in the VLAN control for legacy mode while this feature
> fills that gap.
> Today user can either set a single VLAN id to a VF or none there's
> nothing in between.
> This feature complements  the missing part of the puzzle and we don't
> see any further
> future development in this area after this.
> 
> We have tried to submit and close this gap before (
> https://patchwork.ozlabs.org/patch/806213)
> but messed up there and at the time we decided not to proceed the
> effort
> due to several reasons so we are trying to close this now.
> 
> 
> 

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.

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. 

Thanks,
Saeed.

Powered by blists - more mailing lists