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 23:48:15 +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 Tue, 2019-11-05 at 15:10 -0800, Jakub Kicinski wrote:
> On Tue, 5 Nov 2019 22:52:18 +0000, Saeed Mahameed wrote:
> > > > 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. 
> 
> But switchdev _is_ _here_. _Today_. From uAPI perspective it's done,
> and ready. We're missing the driver and user space parts, but no core
> and uAPI extensions. It's just L2 switching and there's quite a few
> switch drivers upstream, as I'm sure you know :/ 
> 

I can say the same about netlink, it also was there, the missing part
was the netlink ethtool connection and userspace parts .. 

Just because switchdev uAPI is powerful enough to do anything it
doesn't mean we are ready, you said it, user space and drivers are not
ready, and frankly it is not on the road map, and we all know that it
could take years before we can sit back and relax that we got our L2
switching .. Just like what is happening now with ethtool, it been
years you know.. 

> ethtool is not ready from uAPI perspective, still.
> 

ethool is by definition a uAPI only tool, you can't compare the
technical details and challenges of both issue, each one has different
challenges, we need to compare complexity and deprecation policy impact
on consumers.

> It'd be more accurate to compare to legacy IOCTLs, like arguing that 
> we need a small tweak to IOCTLs when Netlink is already there..

Well, no, The right analog here would be:

netlink == switchdev mode
ethtool == legacy mode
netlink-ethtool-interface == L2 bridge offloads 

you do the math.

It is not about uAPI, uAPI could be ready for switchdev mode, maybe, it
just no one even gave this a real serious thought, so i can't accept
that bridge offloads is just around the corner just because switchdev
uAPI feels like ready to do anything, it is seriously not.