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

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

On Thu, May 26, 2016 at 06:00:09PM +0300, Matan Barak wrote:

> >This ensures if we add new function pointers to the end then they are
> >null'd even if libibverbs is older, which is a little safer than
> >overflowing memory.
> 
> In order to use read_xxxx function, a user should allocate a suitable CQ
> (with the correct flag). If a support for a flag is needed in libibverbs, it
> should be checked in the create function.

The purpose is to make the API safer by ensuring null's are present in
unsupported function pointers in case the user accidently calls
them. Of course the user shouldn't call them.

> >The driver should also null fields accessor function pointers that it
> >cannot return.
> 
> We could have checked when creating a QP if the to-be attached CQ doesn't
> support querying invalid attributes in respect of this QP (i.e SLID in RC),
> but doing that you won't be able to attach the same CQ to several QP types
> and get various QP-type specific attributes, as you can today. Thus, we
> prefer the current approach.

Hum, this is an interesting point.

My inclination is to prefer safety over generality, a CQ should not be
bound to a QP that cannot provide all the attributes the CQ is setup
for.

Requiring an app to have a few CQs of different types does not seem
like a significant burden, and directly prevents stupid mistakes on
the part of the user.

> The fields that the user requested are guaranteed to be correct only when
> querying a completion originated by a supporting QP - exactly like today. We
> of course nullify function pointers the user didn't request.

I've always thought that was confusing and hard to use, to be
honest...

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