RE: [PATCH V5 libibverbs 0/7] Completion timestamping

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> 
> On 6/1/2016 6:49 PM, Steve Wise wrote:
> >
> >
> > <snip>
> >
> >>
> >> The batching API is thread-safe (assuming the CQ wasn't created with
> >> SINGLE_THREADED attribute) and represents a series of completions the user
> >> would like to poll one after another.  The vendor user space driver should
> >> guarantee this.
> >>
> >
> > Hey Yishai,
> >
> > Can you please explain how multiple threads can use this API concurrently?
I
> > don't understand how two threads can be in the middle of the next branch
> > concurrently?  Is only one thread allowed in at a time for a
> > start/next/next/.../end branch?
> 
> When a CQ is created with the new API the application states whether
> it's going to be used by a single thread or not. The vendor (e.g.
> libmlx5) based on that will hook its underlying functions for the
> start/next/end for this CQ.
> 
> In case the CQ going to be used by multiple threads the vendor will take
> a lock as part of the start and release it as part of the end,
> preventing any other thread to run in the middle of this batch. This
> logic for multi-threaded application is similar to what happened today
> when ibv_poll_cq is called.
> 
> As mentioned, the new API gives an option to enjoy from stating that the
> CQ will be used by one thread comparing current legacy API which has no
> idea and always use lock/unlock per ibv_poll_cq call.
> 
> You can look in the libmlx5 implementation that I sent today and see the
> above behavior.

Thanks.  This makes sense. 

Steve.

--
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