netdev - Re: pull-request: mlx5-next 2023-01-24 V2

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]

Message-ID: <Y+Q95U+61VaLC+RJ@nvidia.com>
Date:   Wed, 8 Feb 2023 20:27:17 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        Leon Romanovsky <leon@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, linux-rdma@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: pull-request: mlx5-next 2023-01-24 V2

On Wed, Feb 08, 2023 at 03:19:22PM -0800, Jakub Kicinski wrote:
> On Wed, 8 Feb 2023 12:13:00 -0400 Jason Gunthorpe wrote:
> > On Tue, Feb 07, 2023 at 02:03:30PM -0800, Jakub Kicinski wrote:
> > > > I also would like to not discuss this :)  
> > > 
> > > Well, then... Suggest a delineation or a way forward if you don't like
> > > mine. The circular conversation + RDMA gets its way has to end sooner
> > > or later.  
> > 
> > I can't accept yours because it means RDMA stops existing. So we must
> > continue with what has been done for the last 15 years - RDMA
> > (selectively) mirrors the IP and everything running at or below the IP
> > header level.
> 
> Re-implement bits you need for configuration, not stop existing.

This is completely technically infeasible. They share IP addresess, we
cannot have two stacks running IPSEC on top of othe same IP address
without co-ordinating. Almost every part is like that to some degree.

And even if we somehow did keep things 100% seperated, with seperated
IPs - Linus isn't going to let me copy and paste the huge swaths of
core netdev code required to do IP stuff (arp, nd, routing, icmp,
bonding, etc) into RDMA for a reason like this.

So, it really is a complete death blow to demand to keep these things
separated.

Let alone what would happen if we applied the same logic to all the
places sharing the IP with HW - remember iscsi? FCoE?

> > > So "Make it all the same". Now you're saying hyperscalers have their
> > > own standards.  
> > 
> > What do you mean? "make it all the same" can be done with private or
> > open standards?
> 
> Oh. If it's someone private specs its probably irrelevant to the open
> source community?

No, it's what I said I dislike. Private specs, private HW, private
userspace, proprietary kernel forks, but people still try to get
incomplete pieces of stuff into the mainline kernel.

> Sad situation. Not my employer and not in netdev, I hope.

AFAIK your and my employer have done a good job together on joint
projects over the years and have managed to end up with open source
user spaces for almost everything subtantive in the kernel.

> > I have no idea how you are jumping to some conclusion that since the
> > RDMA team made their patches it somehow has anything to do with the
> > work Leon and the netdev team will deliver in future?
> 
> We shouldn't reneg what was agreed on earlier.

Who reneg'd? We always said we'd do it and we are still saying we plan
to do it.

> > Hasn't our netdev team done enough work on TC stuff to earn some
> > faith that we do actually care about TC as part of our portfolio?
> 
> Shouldn't have brought it up in the past discussion then :|
> Being asked to implement something tangential to your goals for 
> the community to accept your code is hardly unheard of.

We agreed to implement. I'm asking for patience since we have a good
historical track record.

Jason