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 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.

Jason



[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