James Lentini wrote:
I expect that the IB_CM_REQ_RECEIVED callback will be confusing to
ULPs. The ULP will receive a new cma_id with an old context value.
If the ULP wanted to make an adjustments to the cma_id that
received the request, it would need to store a reference to it in
the old cma_id's context value. I suggest you make the new cma_id
part of the event data (see patch below).
The new cma_id must be used after the REQ is received, so I wanted to make
that clear. There's not much that a user can do with the listening cma_id
from within the callback; since it cannot be destroyed from the callback
itself. This is a fairly minor issue that we can discuss more.
Fair enough. A comment that says the callback context is not strictly
tied to the cma_id would help here.
The IB CM does this a little differently that your proposal. It returns the new
cm_id in the callback, with a reference to the listen_id in the event. For
consistency, we may want to match this model.
With the CMA, I took out the listen_id, assuming that the user could get to it
using the returned context. I see your point about the context being confusing.
Another approach is to return the context directly in the callback.
Note that nothing prevents the user from changing the context stored with a
cma_id. It's only by default that a new cma_id is created with a context value
equal to that of the listening request.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
