[openib-general] error return values from userspace calls

Pete Wyckoff pw at osc.edu
Fri Aug 4 12:50:23 PDT 2006


I'm going batty trying to figure out how to convert return
codes from the various ibv_ and rdma_ functions into printable
error strings.

Consider ibv_modify_qp.  It goes through the device function and
into ibv_cmd_modify_qp, which then returns 0 or the positive errno
that glibc sets on a failed write(), like +EINVAL.  So I can call
strerror(ret) and get something meaningful.  Fine.

But ibv_query_device.  At least the mthca version returns negative
error codes, like -ENOMEM.  The ibv_cmd version returns the positive
glibc write errno again.  Now I should take the absolute value then
call strerror?

Then ibv_get_async_event.  If the read() fails, it returns -1 but
there presumably is a glibc errno that could be looked at.  Check
for return of -1, and if so, do strerror(errno)?

Then there's ibv_poll_cq that  returns +npolled on sucess, -1 on
empty, -2 on error.  Why not EAGAIN instead of these custom codes?

Maybe some of this is bugs.  Any general consensus on what the
official pattern should be?  It would make coders' lives easier if
there were a single error-reporting style.


The RDMA CM functions follow a different convention pretty
consistently.  They return negative errnos like -EINVAL on error.
Except they do not interpret system call return values that show up
in errno:

int rdma_get_cm_event(..)
{
	..
	if (!event)
		return -EINVAL;
	..
        ret = write(channel->fd, msg, size);
        if (ret != size) {
                free(evt);
                return (ret > 0) ? -ENODATA : ret;
        }

So my user code tries to react as:

	ret = rdma_get_cm_event(..);
	if (ret) {
		if (ret == -1)   /* assume a kernel error, not EPERM */
			printf("died in the kernel: %s\n", strerror(errno));
		else
			printf("user library unhappy: %s\n", strerror(-ret));
	}

Does this seem like the right approach to looking at the return
values?  Maybe these should all be changed to work like their ibv_
relatives?

		-- Pete




More information about the general mailing list