On Thu, 2019-01-31 at 12:29 +0000, Wan, Kaike wrote: > > -----Original Message----- > > From: Dalessandro, Dennis > > Sent: Wednesday, January 30, 2019 5:38 PM > > To: Jason Gunthorpe <jgg@xxxxxxxx> > > Cc: Doug Ledford <dledford@xxxxxxxxxx>; Dixit, Ashutosh > > <ashutosh.dixit@xxxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx; Marciniszyn, Mike > > <mike.marciniszyn@xxxxxxxxx>; Wan, Kaike <kaike.wan@xxxxxxxxx> > > Subject: Re: [PATCH for-next 00/23] IB/hfi1: Add TID RDMA Write > > > > 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. > > > The three series are incrementally built, i.e, the TID RDMA READ series depends on OPFN series, and the TID RDMA WRITE series depends on both OPFN and TID RDMA READ series. Therefore, you should apply OPFN first, and TID RDMA READ, and lastly TID RDMA WRITE. Each stop (OPFN, OPFN + READ, OPFN + READ +WRITE) have been fully tested and functional. For the sake of "completeness of code" when it get merged, I'll do the three individually, but in their own branch, and then finally merge that branch back to for-next. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
