Re: [PATCH for-next 00/23] IB/hfi1: Add TID RDMA Write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/30/2019 5:45 PM, Jason Gunthorpe wrote:
On Wed, Jan 30, 2019 at 05:37:30PM -0500, Dennis Dalessandro wrote:
On 1/30/2019 5:01 PM, Jason Gunthorpe wrote:
On Wed, Jan 30, 2019 at 04:45:45PM -0500, Dennis Dalessandro wrote:
[Drop Mitko's dead email address]

On 1/30/2019 4:19 PM, Jason Gunthorpe wrote:
On Wed, Jan 30, 2019 at 12:54:04PM -0500, Dennis Dalessandro wrote:
On 1/30/2019 12:21 PM, Doug Ledford wrote:
On Wed, 2019-01-23 at 21:48 -0800, Dennis Dalessandro wrote:
Here is the final set of patches for TID RDMA. Again this is code which was
previously submitted but re-organized so as to be easier to review.

Similar to how the READ series was organized the patches to build, receive,
allocate resources etc are broken out. For details on TID RDMA as a whole
again refer to the original cover letter.

https://www.spinics.net/lists/linux-rdma/msg66611.html

Help me out here Denny.  This appears to be a *monster* submission.  Are
you saying we need all of these patch series to make this work:

Subject:	[PATCH for-next 00/17] IB/hfi1: Add TID RDMA Read
Subject:	[PATCH for-next 0/6] IB/hfi1: Add OPFN
Subject:	[PATCH for-next 00/23] IB/hfi1: Add TID RDMA Write

So a total of 46 patches to add this support?  And do the series need to
be in that order?

Yes it is certainly a monster series. Same code in the end as we submitted
before, Kaike just did a big re-org job on it all so it flows better for
review.

The point of the re-org was to get into the standard accepted flow of
~14 patches sent and applicable on their own, not to just re-organize
the 50 patches into a different set of 50 patches.

The code was all re-organized specifically for the "flow". Yeah it's a large
number of patches but it's logically all arranged and not a set of 50
hodge-podge patches. Logically these do stand on their own. We have the
negotiation, we have the read, then we have the right. I don't see how
breaking things up even more is going to help much. Open to suggestions
though.

You said that if they get applied they might not work, so the
individual series are untested?

Kinda misspoke there. If you apply OPFN and stop, things are fine. If you
apply OPFN and skip the read and go to the write. That I'm not sure about.
But adding each series in succession things will work at each stop along the
way.

Just taking a quick look through my mail box I see more than a couple series
that are larger than 14. Including a 30 patch series that didn't seem to
generate any complaints.

NFS seems to have different rules..

So are you setting a hard rule in stone here? No series over 14 patches?

No.. approx 14 is the general guideline netdev uses, with random
exceptions it seems.

Other trees do different things, but rdma is somewhat modeled on
netdev practices.


Ok so what does this mean then for this series? Is it going to be a random exception or do you really want to see something else here.

-Denny




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux