[dpdk-dev] A question of DPDK ring buffer

["Bob Chen" <beef9999@qq.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1882 bytes --]

Hi folks,


Is there anyone who has researched the mechanism of DPDK ring buffer by any chance? I was trying to understand the multi-producer and muti-consumer scenario, the CAS(compare and swap) operation is not an obstacle to me, and from what I can tell, the method which DPDK adopts is basically lock-free, not wait-free.


What troubles me is the last wait operation when each core has fulfilled its enqueued objects and then stop there waiting the public structure prod_tail to match its private per core structure prod_head. Only if public prod_tail equals to its private prod_head, it will increase the public prod_tail to private prod_next. See below, from DPDK programmer guide.



	/*
	 * If there are other enqueues in progress that preceeded us,
	 * we need to wait for them to complete
	 */
	while (unlikely(r->prod.tail != prod_head))
		rte_pause();



The final position of public prod_tail is the same to public prod_head. That means they have reached to the initial state.



OK, here is the question: Why DPDK has to maintain that public prod_tail structure? Is it really necessary to endure a while loop here? I think in a circumstance of heavy workload, it might be very likely that a core enqueues its own data in advance, however, it needs to wait the others to finish enqueueing even though it already has nothing to do at that time. It seems to me that even if we remove the public prod_tail structure, the enqueue operation is still able to work. Because each core has known the exact enqueue position from its private prod_head and prod_next. In another word, we just need to assure the correctness of per core pointer and leave the rest of the enqueue work to that particular core. Those per core pointers they never overlap according to the CAS atomic operation, that is our assumption.


What do you reckon?


Regards,
Bob

[-- Attachment #1.2: Type: text/html, Size: 2992 bytes --]

[-- Attachment #2: D8D96AE0@BC70CD7F.70F21252.96F01252 --]
[-- Type: application/octet-stream, Size: 11844 bytes --]

[-- Attachment #3: D8E46A1B@BC70CD7F.70F21252.96F01252 --]
[-- Type: application/octet-stream, Size: 46451 bytes --]