On Thu, 2019-01-31 at 12:35 +0000, Wan, Kaike wrote: > > -----Original Message----- > > From: Doug Ledford [mailto:dledford@xxxxxxxxxx] > > Sent: Wednesday, January 30, 2019 2:32 PM > > To: Dalessandro, Dennis <dennis.dalessandro@xxxxxxxxx>; jgg@xxxxxxxx > > Cc: Dixit, Ashutosh <ashutosh.dixit@xxxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx; > > Mitko Haralanov <mitko.haralanov@xxxxxxxxx>; Marciniszyn, Mike > > <mike.marciniszyn@xxxxxxxxx>; Wan, Kaike <kaike.wan@xxxxxxxxx> > > Subject: Re: [PATCH for-next 0/6] IB/hfi1: Add OPFN > > > > On Wed, 2019-01-23 at 19:20 -0800, Dennis Dalessandro wrote: > > > This is the second in a set of patch series to add in TID RDMA. This > > > series is the patches to support OPFN which is the feature negotiation > > > protocol used by TID RDMA. This is totally hidden from users and does > > > not impact any API. It done under the hood at the driver level. > > > > > > At a high level OPFN enables exchanging parameters between two hosts > > > using IB compare and swap requests to a special virtual address. The > > > request uses a reserved IB work request opcode (see patch 3). > > > > I looked it over, and I didn't see any red flags. None of the obvious NAK type > > stuff anyway. My only concern is a matter of precedent. > > You're hijacking a bit to represent a single driver handled, in-band > > negotiation. Given that it's only on OPA links, and I suspect you're going to > > say it's backward compatible and won't prevent older drivers from talking to > > newer drivers, I'm OK with that generally. But I wonder if you should be > > doing one bit, one extension, or a single "I have in- band, driver local features > > to discuss" bit and then the negotiation protocol handles what features are > > available. I'm thinking of this from a future extension standpoint. If you guys > > have plans for more changes like this, then something other than one bit per > > feature might be the better option. > > > We are doing a single "I have in-band, driver local features to discuss" approach here (one bit for all future features) and future extension can be easily done by adding features in OPFN itself. Ok. Mainly because of the way you had things named, I took it to be a bit per feature. I'm glad that's not the case. Thanks for the clarification. -- 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
