Message-ID: <Y+PKDOyUeU/GwA3W@nvidia.com>
Date:   Wed, 8 Feb 2023 12:13:00 -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 Tue, Feb 07, 2023 at 02:03:30PM -0800, Jakub Kicinski wrote:
> > In the end the fight was ideological around what is open enough to be
> > inside Linux because the GPU devices were skirting around something of
> > a grey area in the project's philosophy on how much open user space is
> > actually required.
> 
> Right, I see that as very similar to our situation.

Er, not at all. As I've explained many times now RDMA is well aligned
with mainstream Linux ideology on code openness.

> > > Good fences make good neighbors so I'd like to build a fence and
> > > avoid having to discuss this over and over.  
> > 
> > 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.

> > An open source kernel implementation of a private standard for HW that
> > only one company can purchase that is only usable with a proprietary
> > userspace. Not exactly what I'd like to see.
> 
> You switched your argument 180 degrees.
> 
> Fist you said:
> 
>   What you posted about your goals for netdev is pretty consistent with
>   the typical approach from a hyperscaler purchasing department: Make it
>   all the same. Grind the competing vendors on price.
> 
> 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?

> > Ah, I stumble across stuff from time to time - KVM and related has
> > some interesting things. Especially with this new confidential compute
> > stuff. AMD just tried to get something into their mainline iommu
> > driver to support their out of tree kernel, for instance.
> > 
> > People try to bend the rules all the time.
> 
> AMD is a vendor, tho, you said "trend of large cloud operators pushing
> things into the kernel". I was curious to hear the hyperscaler example
> 'cause I'd like to be vigilant.

I'm looking at it from the perspective of who owns, operates and
monetizes the propritary close source kernel fork. It is not AMD.

AMD/Intel/ARM provided open patches to a hyperscaler(s) for their CC
solutions that haven't been merged yet. The hyperscaler is the one
that forked Linux into closed source, integrated them and is operating
the closed solution.

That the vendor pushes little parts of the hyperscaler solution to the
kernel & ecosystem in a trickle doesn't make the sad state of affairs
exclusively the vendors fault, even if their name is on the patches,
IMHO.

> > The ipsec patches here have almost 0 impact on netdev because it is a
> > tiny steering engine configuration. I'd have more sympathy to the
> > argument if it was consuming a huge API surface to do this.
> 
> The existence of the full IPsec offload in its entirety is questionable.
> We let the earlier patches in trusting that you'll deliver the
> forwarding support. We're calling "stop" here because when the patches
> from this PR were posted to the list we learned for the first time
> that the forwarding is perhaps less real than expected.

ipsec offload works within netdev for non switch use cases fine. I
would think that alone is enough to be OK for netdev.

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?

> > > The simplest way forward would be to commit to when mlx5 will
> > > support redirects to xfrm tunnel via tc...  
> > 
> > He needs to fix the bugs he created and found first :)
> > 
> > As far as I'm concerned TC will stay on his list until it is done.
> 
> This is what I get for trusting a vendor :/
> 
> If you can't make a commitment my strong recommendation is for this code
> to not be accepted upstream until TC patches emerge.

This is the strongest commitment I am allowed to make in public.

I honestly have no idea why you are so fixated on TC, or what it has
to do with RDMA.

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?

Jason

Powered by blists - more mailing lists