>>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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
