Re: [PATCH V4 libibverbs 2/7] Add member functions to poll an extended CQ

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, May 31, 2016 at 05:46:38PM +0000, Hefty, Sean wrote:

> These are more thoughts than questions: If an app wants to support
> iWarp/RoCE/OPA, is it just going to have a branch around the calls
> anyway?

This doesn't really change one way or the other, apps have to
understand what attributes are available on the CQ and do whatever
branching is needed to access them.

It is a good question if we should have different accessors, like
get_src_addr(buf,sizeof(buf)) or something that can handle the other
protocols with less hassle.

But at the end of the day, the user will still have to cast the buf to
the right type...

> What data is actually needed by the apps?

The apps decide when they create the CQ what things the CQ is needed
to return. So apps are in control. Are you musing if some of these are
needed or not?

Oh, that reminds me: Yishai, please purge pkey_index from the new
API. It was a mistake in the old API, the standard says it is only
valid for QP1, and we don't support QP1 in user space. Any app that
uses pkey_index is broken. It was a mistake to ever expose this to
userspace.

> Is there any relationship between the various calls?  For example,
> if an app calls read_slid, is it more likely than not to also call
> read_pkey_index and read_dlid_path_bits, etc.?
> Is the app expected to retrieve addressing data piecemeal like this
> for every possible architecture?  Are 5 function calls better than
> one call that fills out a structure, when all fields are needed?

There are certainly logical groups, eg the various path parameters are
almost always going to be needed together.

I was asking this same question.. I think the response was that
memcpying into a stack struct was more expensive than the branches..

I'm skeptical of that, but maybe if the C ABI doesn't use return value
optimization like C++ does it could get a bit costly....

Even so, it seems like an easier API for the end user...

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html