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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://dpdk.org/ml/archives/dev/attachments/20130820/2b4ad6a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D8D96AE0 at BC70CD7F.70F21252.96F01252
Type: application/octet-stream
Size: 11844 bytes
Desc: not available
URL:
<http://dpdk.org/ml/archives/dev/attachments/20130820/2b4ad6a5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D8E46A1B at BC70CD7F.70F21252.96F01252
Type: application/octet-stream
Size: 46451 bytes
Desc: not available
URL:
<http://dpdk.org/ml/archives/dev/attachments/20130820/2b4ad6a5/attachment-0001.obj>
