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