[Ofvwg] OpenFabrics Verbs Working Group meeting minutes 3/24/15

[Gilad Shainer]

ORNL
Mellanox
Intel
Chelsio
LANL
OSU
Oracle
IBM
Software Forge


1. A brief summary of the feedbacks from OFA F-2-F meeting. (Liran and Pavel)

2. Overview and follow-up discussion on the Accelerated Verbs subject
Liran presented the latest proposal of Accelerated Verbs as presented in OFA'15 developer's workshop, which incorporates the comments collected from the last OVFWG meeting on this subject. Also, feedback obtained regarding Verbs accelerations from the workshop was presented.
The framework was reviewed in the meeting and the following observations were agreed upon:
-          The fundamental concept of querying an object for a specific accelerated interface, and releasing the interface
-          The notion of formally qualifying an interface family by scope
-          The notion of formally qualifying an interface by version, with the following semantic guarantees by a provider:
- Any version shall implement all methods of prior versions
- The methods of prior versions should maintain their original order in the function jump table
In addition, several discussions were held on detailed issues. Specifically:
Pasha asked how can applications rely on scope guarantees. Liran replied that the scope enumeration definition shall be part of the upstream Verbs header file, which will always maintain backward compatibility.
Bernard asked whether the returned interfaces would be implemented directly by the provider or first go through generic wrappers. Liran replied that since interfaces are obtained for already configured objects, there is no apparent reason to go through wrappers. In fact, data-path Verbs today are already dispatched directly to the provider implementation.
ARs:
-          Make a semantic requirement that interface lifetimes are bound the timeframe for which the associated object does not change.
-          Define in the header files / MAN pages the semantics of "object doesn't change"...
The notion of representing interfaces as integers was discussed (vs. enums or some other representation). It was agreed that this is reasonable since within each scope, new interfaces may be defined by enumerations. Also, since each scope defines a different enumeration, it makes no sense to put into 'struct ibv_query_intf_params' the enum type.
Pasha asked how the application can determine that an interface may be used for 2 different objects of the same type, and suggested adding a comparison function to the API. Liran answered that  in general the application can never make this assumption (because it can't know what 2 different objects constitute "the same type"), but the application can always compare the returned interface pointers obtained from 2 queries, and if they are the same, save only one of them. Moshe L asked if this doesn't restrict the applicability of sharing functions if providers happen to return different pointers. Liran answered that interfaces are semantically "Pure Abstract Classes" in OOP, so by definition, hold no state. Therefore, providers don't have any reason to allocate different interfaces for 2 objects that they consider the same. A follow up question was whether functions can be shared at the method level rather than the interface level. Liran answered that the same pointer-comparing technique is always guaranteed to be correct, so applications can share methods between objects as long as their pointers are the same, even if the returned interface pointers for these objects were different.
Finally, a suggestion of adding an addition "Vendor experimental" scope was raised.
This seems like a good idea so this notion doesn't need to be implemented differently by every vendor.
AR:
-          Add a vendor experimental scope


Regards,
Gilad Shainer
Vice President, Marketing
Mellanox Technologies
350 Oakmead Parkway, Suite 100, Sunnyvale CA, 94085
Office: 408-916-0048, Mobile: 408-421-0048, Fax: 408-585-0348

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofvwg/attachments/20150325/fde6ae80/attachment.html>