> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
