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

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

On Sun, May 29, 2016 at 06:38:41PM -0400, Doug Ledford wrote:
 
> So I've been busy with kernel stuff, but I don't really like this patch.
>  I'm not really enamored with the entire poll_ex API.

You should really read the whole prior discussion

> First, I don't like the start_poll/poll/end_poll setup.  I would rather
> we do something like using refcounting on the WCs.  Maybe something like
> returning an array of pointers to WCs where each WC already has a
> ref

Refs? Yuk. That doesn't fit the typical use model, and refs
involve more expensive locking per wc.

> When a cq is created by the driver, it is responsible for filling out
> the offsets array (can be static if your driver only has one CQE
> format,

*shrug* Careful benchmarking would have to prove if this is better or
not. Based on Yishai's comments I expect it is not better, since I
expect an offsets array to perform worse than the original bitmask
thing.

Yishai's said this benchmarked better than the bitmask and equal to
or better than today's versions..

This is a whole picture optimization and the user side is only one
part of the equation - the function pointer scheme is also optimizing
the driver path quite heavily, which is why it is showing positively
in benchmarks.

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