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