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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
