linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	"Rimmer, Todd" <todd.rimmer@intel.com>,
	"Wan, Kaike" <kaike.wan@intel.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH RFC 0/9] A rendezvous module
Date: Sun, 21 Mar 2021 13:45:04 -0300	[thread overview]
Message-ID: <20210321164504.GS2356281@nvidia.com> (raw)
In-Reply-To: <bc56284b-f517-2770-16ec-b98d95caea6f@cornelisnetworks.com>

On Sun, Mar 21, 2021 at 12:24:39PM -0400, Dennis Dalessandro wrote:
> On 3/21/2021 4:56 AM, Leon Romanovsky wrote:
> > On Sat, Mar 20, 2021 at 12:39:46PM -0400, Dennis Dalessandro wrote:
> > > On 3/19/2021 6:57 PM, Rimmer, Todd wrote:
> > > > > > [Wan, Kaike] Incorrect. The rv module works with hfi1.
> > 
> > <...>
> > 
> > > > We have removed all GPU specific code from the upstream submission, but used both the "alignment holes" and the "reserved"
> > > > mechanisms to hold places for GPU specific fields which can't be upstreamed.
> > > 
> > > This problem extends to other drivers as well. I'm also interested in advice
> > > on the situation. I don't particularly like this either, but we need a way
> > > to accomplish the goal. We owe it to users to be flexible. Please offer
> > > suggestions.
> > 
> > Sorry to interrupt, but it seems that solution was said here [1].
> > It wasn't said directly, but between the lines it means that you need
> > two things:
> > 1. Upstream everything.
> 
> Completely agree. However the GPU code from nvidia is not upstream. I don't
> see that issue getting resolved in this code review. Let's move on.
> 
> > 2. Find another vendor that jumps on this RV bandwagon.
> 
> That's not a valid argument. Clearly this works over multiple vendors HW.

At a certain point we have to decide if this is a generic code of some
kind or a driver-specific thing like HFI has.

There are also obvious technial problems designing it as a ULP, so it
is a very important question to answer. If it will only ever be used
by one Intel ethernet chip then maybe it isn't really generic code.

On the other hand it really looks like it overlaps in various ways
with both RDS and the qib/hfi1 cdev, so why isn't there any effort to
have some commonality??

> We should be trying to get things upstream, not putting up walls when people
> want to submit new drivers. Calling code "garbage" [1] is not productive.

Putting a bunch of misaligned structures and random reserved fields
*is* garbage by the upstream standard and if I send that to Linus I'll
get yelled at.

And you certainly can't say "we are already shipping this ABI so we
won't change it" either.

You can't square this circle by compromising the upstream world in any
way, it is simply not accepted by the overall community.

All of you should know this, I shouldn't have to lecture on this!

Also no, we should not be "trying to get things upstream" as some goal
in itself. Upstream is not a trashcan to dump stuff into, someone has
to maintain all of this long after it stops being interesting, so
there better be good reasons to put it here in the first place.

If it isn't obvious, I'll repeat again: I'm highly annoyed that Intel
is sending something like this RV, in the state it is in, to support
their own out of tree driver, that they themselves have been dragging
their feet on responding to review comments so it can be upstream for
*years*.

Jason

  reply	other threads:[~2021-03-21 16:46 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 12:56 [PATCH RFC 0/9] A rendezvous module kaike.wan
2021-03-19 12:56 ` [PATCH RFC 1/9] RDMA/rv: Public interferce for the RDMA Rendezvous module kaike.wan
2021-03-19 16:00   ` Jason Gunthorpe
2021-03-19 12:56 ` [PATCH RFC 2/9] RDMA/rv: Add the internal header files kaike.wan
2021-03-19 16:02   ` Jason Gunthorpe
2021-03-19 12:56 ` [PATCH RFC 3/9] RDMA/rv: Add the rv module kaike.wan
2021-03-19 12:56 ` [PATCH RFC 4/9] RDMA/rv: Add functions for memory region cache kaike.wan
2021-03-19 12:56 ` [PATCH RFC 5/9] RDMA/rv: Add function to register/deregister memory region kaike.wan
2021-03-19 12:56 ` [PATCH RFC 6/9] RDMA/rv: Add connection management functions kaike.wan
2021-03-19 12:56 ` [PATCH RFC 7/9] RDMA/rv: Add functions for RDMA transactions kaike.wan
2021-03-19 12:56 ` [PATCH RFC 8/9] RDMA/rv: Add functions for file operations kaike.wan
2021-03-19 12:56 ` [PATCH RFC 9/9] RDMA/rv: Integrate the file operations into the rv module kaike.wan
2021-03-19 13:53 ` [PATCH RFC 0/9] A rendezvous module Jason Gunthorpe
2021-03-19 14:49   ` Wan, Kaike
2021-03-19 15:48     ` Jason Gunthorpe
2021-03-19 19:22       ` Dennis Dalessandro
2021-03-19 19:44         ` Jason Gunthorpe
2021-03-19 20:12           ` Rimmer, Todd
2021-03-19 20:26             ` Jason Gunthorpe
2021-03-19 20:46               ` Rimmer, Todd
2021-03-19 20:54                 ` Jason Gunthorpe
2021-03-19 20:59                   ` Wan, Kaike
2021-03-19 21:28                     ` Dennis Dalessandro
2021-03-19 21:58                       ` Wan, Kaike
2021-03-19 22:35                         ` Jason Gunthorpe
2021-03-19 22:57                       ` Rimmer, Todd
2021-03-19 23:06                         ` Jason Gunthorpe
2021-03-20 16:39                         ` Dennis Dalessandro
2021-03-21  8:56                           ` Leon Romanovsky
2021-03-21 16:24                             ` Dennis Dalessandro
2021-03-21 16:45                               ` Jason Gunthorpe [this message]
2021-03-21 17:21                                 ` Dennis Dalessandro
2021-03-21 18:08                                   ` Jason Gunthorpe
2021-03-22 15:17                                     ` Rimmer, Todd
2021-03-22 16:47                                       ` Jason Gunthorpe
2021-03-22 17:31                                     ` Hefty, Sean
2021-03-23 22:56                                       ` Jason Gunthorpe
2021-03-23 23:29                                         ` Rimmer, Todd
2021-03-21 19:19                                   ` Wan, Kaike
2021-03-23 15:36                                   ` Christoph Hellwig
2021-03-23 15:35                                 ` Christoph Hellwig
2021-03-23 15:33                               ` Christoph Hellwig
2021-03-23 15:30                         ` Christoph Hellwig
2021-03-23 15:46                           ` Jason Gunthorpe
2021-03-23 16:07                             ` Christoph Hellwig
2021-03-23 17:25                               ` Rimmer, Todd
2021-03-23 17:44                                 ` Jason Gunthorpe
2021-03-19 20:18           ` Dennis Dalessandro
2021-03-19 20:30             ` Jason Gunthorpe
2021-03-19 20:34       ` Hefty, Sean
2021-03-21 12:08         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210321164504.GS2356281@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dennis.dalessandro@cornelisnetworks.com \
    --cc=dledford@redhat.com \
    --cc=kaike.wan@intel.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=todd.rimmer@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).