[Ofvwg] OFVWG meeting notes - 8/4/2015

[Liran Liss]

We observed that the current Verbs API may be classified according to their means of reporting errors:

-          Functions that return errno values

-          Functions that return NULL

-          Functions that return -1 or "a negative value"

-          Functions that cannot fail

Examples of each class were presented.
For backward compatibility reasons, it is not desirable to merge these classes. For example, applications that tested calls with  -1 or negative values might fail if the same call returned a positive errno.

However, updating errno seems like a good practice in all cases. For example, ibv_query_gid() and ibv_query_pkey() could distinguish between an IO error and a range check failure.
For functions that return errno code directly, the value of errno is undefined.

The error codes previously discussed for ibv_post_send() seem to be a good match for other posting functions.
Namely EINVAL for WQEs that exceed device capabilities and EBUSY when a queue is full.

In ibv_poll_cq(), extending the standard completion errors seems like a good way to report more detailed errors. However, we might want to distinguish between these extensions and the completion codes defined in the standards.

The ibv_modify_qp() Verb needs to be handled as a special case due to the various failure modes, which include:

-          Invalid state transitions

-          Missing parameters in a given state transition

-          Redundant parameters in a given state transition

-          Invalid values
Defining an extended version of this function which provides the details of these failures seems to be the right way to go.

In ibv_create_qp(), it might be a good idea to distinguish between the cases that are currently reported as EINVAL, such as invalid queue depth, number of SGEs, and inline data. However, other creation functions have either trivial or very few parameters.
So, it is not sure that these cases justify a new generic reporting mechanism.

In any case, it seems a good practice to distinguish between ENOMEM and the case that a certain resource has been exhausted. This could be returned as just a different errno code (TBD).

Destruction functions usually return standard system call processing errors such as EFAULT (can't access user pointer) / ENOMEM (while allocating temporary structures for processing) / EINVAL (invalid object handle). However, when the error stems from an internal error of the provider driver, EIO seems like a good option.

In addition. EBUSY should be reported for resources that are referenced by other resources.
This seems like the consistent behavior today, but should be documented in the MAN pages.

Error flows specific to extended Verbs is a subject for future discussions.

--Liran


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