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

From: Saeed Mahameed <saeedm@mellanox.com>
To: "jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>
Cc: "sbrivio@redhat.com" <sbrivio@redhat.com>,
	"nikolay@cumulusnetworks.com" <nikolay@cumulusnetworks.com>,
	"dsahern@gmail.com" <dsahern@gmail.com>,
	"sd@queasysnail.net" <sd@queasysnail.net>,
	Jiri Pirko <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	Ariel Levkovich <lariel@mellanox.com>
Subject: Re: [PATCH net-next v2 0/3] VGT+ support
Date: Tue, 5 Nov 2019 22:52:18 +0000	[thread overview]
Message-ID: <8c740914b7627a10e05313393442d914a42772d1.camel@mellanox.com> (raw)
In-Reply-To: <20191105135536.5da90316@cakuba.netronome.com>

On Tue, 2019-11-05 at 13:55 -0800, Jakub Kicinski wrote:
> 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.
> 

bridge offloads is not on the road map. same as for netlink ethtool
adapter which is still WIP since 2017.

> > 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.
> 

Again, not because cheaper, considering the circumstances and the
basicness of this feature, this is the only right way to go for this
particular case.

> > 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.
> 

And picking on basic/simple extensions will get you there ? i doubt it.

Being strict is one thing and I totally agree with the motivation, but
I strongly disagree with this total shutdown policy with no
alternatives and no real grounds other than the hope someone would
eventually listen and implement the migration path, meanwhile ALL users
MUST suffer regardless how trivial or basic their request is.

> > 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?

Obviously, no one would have agreed to such total shutdown for ethtool,
we eventually decided not to block ethtool unless we have the netlink
adapter working .. legacy mode should get the same treatment.

Bottom line for the same reason we decided that ethtool is not totally
dead until ethtool netlink interface is complete, we should still
support selective and basic sriov legacy mode extensions until bridge
offloads is complete. 