From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: A question of DPDK ring buffer Date: Wed, 21 Aug 2013 10:31:29 +0200 Message-ID: <52147AE1.4030000@6wind.com> References: <5213272C.4060101@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev To: "Chen, Bo D" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Bob, > do { > prod_head = r->prod.head; > cons_tail = r->cons.tail; > prod_next = prod_head + n; > success = rte_atomic32_cmpset(&r->prod.head, prod_head, prod_next); > > /* > * Why not enqueue data here? It would be just a couple of pointers assignment, not taking too much time. > * Then the entire CAS loop contains both pointer adjustment and data enqueue, and the dequeue operation would not have a chance to interfere data producing. > * The next wait loop can be removed accordingly. > /* You cannot enqueue your data here: before writing the objects, you must first check that the cmpset is succesful. In your example, if the cmpset fails, it would write the objects pointer in a zone already reserved by another producer core. The writing of objects must be done after the "do - while" loop, once cmpset is succesful. But even with that, you cannot remove the wait loop (r->prod.tail != prod_head) for the reasons described in my previous mail. The ring test in app/test/test_ring.c is quite stressful for the rings so you can use it to check that your solution is working. Regards, Olivier