[openib-general] [RFC] [uCM] proposed API changes

[Sean Hefty]

>>I'd like to propose the following changes to the user CM API.  These
>>would allow returning user specified context when reporting events to
>>the user.  I also added a call to retrieve the necessary QP attributes
>>from the kernel CM that I would like to include as a part of the API/ABI
>>changes.  Comments?
>>
>>- Sean
>
>Looks good so far. The context will save uDAPL a list search and the uCM
>QP attributes is a much
>needed feature that I have been anxiously watiting for.

There is an issue with adding context.  When a connection REQ is received, a new
kernel cm_id is created.  This cm_id doesn't have any context associated with
it.  For kernel clients, this isn't a big deal, since all events associated with
a single cm_id are serialized.  A kernel app can set the context as part of
their REQ handling.

Userspace clients will run into the same situation, where no context is defined.
But events for the same cm_id are not serialized for userspace clients.  An app
can receive a REJ event for a newly created cm_id that does not have a context.
(They can even process the REJ event before the REQ event is seen.)  Searching
in this case is unavoidable.  I'm not even sure of the right way to handle this
situation.

In a more generic sense, userspace clients need to be able to handle out of
order events if they use multiple threads for event handling.  For example, MRA
to a REQ, REP received, and REJ received events could all occur at the same
time.  (In this case, a userspace context would be valid.)

- Sean