cv ? 2013-8-20?12:37?"Bob Chen" <beef9999 at qq.com> ???
> 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. > > <D8E46A1B at BC70CD7F.70F21252.96F01252> > /* > * 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. > <D8D96AE0 at BC70CD7F.70F21252.96F01252> > > 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/20130824/fe5bfd5c/attachment.html>
