[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191105135536.5da90316@cakuba.netronome.com>
Date: Tue, 5 Nov 2019 13:55:36 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Saeed Mahameed <saeedm@...lanox.com>
Cc: "dsahern@...il.com" <dsahern@...il.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"sbrivio@...hat.com" <sbrivio@...hat.com>,
"nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
Jiri Pirko <jiri@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"sd@...asysnail.net" <sd@...asysnail.net>,
Ariel Levkovich <lariel@...lanox.com>
Subject: Re: [PATCH net-next v2 0/3] VGT+ support
On Tue, 5 Nov 2019 20:10:02 +0000, Saeed Mahameed wrote:
> > > > 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.
> > >
> > > And this caught my eye as well -- iproute2 does not need the
> > > baggage either.
> > >
> > > Is there any reason this continued support for legacy sriov can
> > > not be done out of tree?
> >
> > Exactly. Moving to upstream is only valuable if it doesn't require
> > brining all the out-of-tree baggage.
>
> this baggage is a very essential part for eth sriov, it is a missing
> feature in both switchdev mode (bridge offloads) and legacy.
AFAIK from uAPI perspective nothing is missing in switchdev mode.
> Guys, I need to know my options here and make some effort assessment.
>
> 1) implement bridge offloads: months of development, years for
> deployment and migration
> 2) Close this gap in legacy mode: days.
>
> I am all IN for bridge offloads, but you have to understand why i pick
> 2, not because it is cheaper, but because it is more realistic for my
> current users. Saying no to this just because switchdev mode is the de
> facto standard isn't fair and there should be an active clear
> transition plan, with something available to work with ... not just
> ideas.
I understand your perspective. It is cheaper for you.
> Your claims are valid only when we are truly ready for migration. we
> are simply not and no one has a clear plan in the horizon, so i don't
> get this total freeze attitude of legacy mode,
There will never be any L2 plan unless we say no to legacy extensions.
> it should be just like ethtool we want to to replace it but we know
> we are not there yet, so we carefully add only necessary things with
> lots of auditing, same should go here.
Worked out amazingly for ethtool, right?
Powered by blists - more mailing lists