From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbg55.qq.com (smtpbg55.qq.com [64.71.138.44]) by dpdk.org (Postfix) with SMTP id 585B81F3 for ; Sat, 24 Aug 2013 16:34:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1377354886; bh=uix+h4v5Bmmyz2ttSMAiIFOc55xesEQQYLyiKZ3K2tc=; h=X-QQ-mid:Received:X-QQ-SSF:Subject:References:From:Content-Type: X-Mailer:In-Reply-To:Message-Id:Date:To:Content-Transfer-Encoding: Mime-Version:X-QQ-FName:X-QQ-LocalIP; b=wYtFoy+dnGsU/4UKb+Gfs0Ev0wfDjm9AJil9wkX/ikvF9nIK041uaFbnU7aTQgVL0 C7kbOMLbR0xGJhlIJWJXiIQvTZ+KpmVQVkrVW66JKxcORHKvvLCz3ZFcJgypH9STMa 1Ruu9+99TRykM2sDuHlAzLPw4/00m/AzvI6OdpfY= X-QQ-mid: esmtp22t1377354883t705t32344 Received: from [192.168.0.103] (unknown [58.23.89.187]) by esmtp4.qq.com (ESMTP) with SMTP id 0 for ; Sat, 24 Aug 2013 22:34:42 +0800 (CST) X-QQ-SSF: 00000000000000F0FxF006000000000 References: From: Beef Content-Type: multipart/alternative; boundary=Apple-Mail-7E3B52B6-16B3-43F3-A598-ADB5E7A041C8 X-Mailer: iPhone Mail (10B143) In-Reply-To: Message-Id: Date: Sat, 24 Aug 2013 22:34:41 +0800 To: dev Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-QQ-FName: D3402B51CE4047BB999B61D0B4FC1DAE X-QQ-LocalIP: 112.95.241.173 Subject: Re: [dpdk-dev] A question of DPDK ring buffer X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 14:34:18 -0000 --Apple-Mail-7E3B52B6-16B3-43F3-A598-ADB5E7A041C8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable cv =D4=DA 2013-8-20=A3=AC12:37=A3=AC"Bob Chen" =D0=B4=B5=C0=A3= =BA > Hi folks, >=20 > Is there anyone who has researched the mechanism of DPDK ring buffer by an= y chance? I was trying to understand the multi-producer and muti-consumer sc= enario, the CAS(compare and swap) operation is not an obstacle to me, and fr= om what I can tell, the method which DPDK adopts is basically lock-free, not= wait-free. >=20 > What troubles me is the last wait operation when each core has fulfilled i= ts enqueued objects and then stop there waiting the public structure prod_ta= il to match its private per core structure prod_head. Only if public prod_ta= il equals to its private prod_head, it will increase the public prod_tail to= private prod_next. See below, from DPDK programmer guide. >=20 > > /* > * If there are other enqueues in progress that preceeded us, > * we need to wait for them to complete > */ > while (unlikely(r->prod.tail !=3D prod_head)) > rte_pause(); >=20 > The final position of public prod_tail is the same to public prod_head. Th= at means they have reached to the initial state. > >=20 > OK, here is the question: Why DPDK has to maintain that public prod_tail s= tructure? Is it really necessary to endure a while loop here? I think in a c= ircumstance of heavy workload, it might be very likely that a core enqueues i= ts own data in advance, however, it needs to wait the others to finish enque= ueing even though it already has nothing to do at that time. It seems to me t= hat even if we remove the public prod_tail structure, the enqueue operation i= s 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 a= ssure the correctness of per core pointer and leave the rest of the enqueue w= ork to that particular core. Those per core pointers they never overlap acco= rding to the CAS atomic operation, that is our assumption. >=20 > What do you reckon? >=20 > Regards, > Bob --Apple-Mail-7E3B52B6-16B3-43F3-A598-ADB5E7A041C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

cv
=E5=9C=A8 2013-8-= 20=EF=BC=8C12:37=EF=BC=8C"Bob Chen" <b= eef9999@qq.com> =E5=86=99=E9=81=93=EF=BC=9A

Hi folks,

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

What troubles me is the last wait operation when each core h= as fulfilled its enqueued objects and then stop there waiting the public str= ucture prod_tail to match its private per core structure prod_head. Only if p= ublic prod_tail equals to its private prod_head, it will increase the public prod_tail to private pro= d_next. See below, from DPDK programmer guide.

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

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 t= he 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 h= eavy workload, it might be very likely that a core enqueues its own data in a= dvance, however, it needs to wait the others to finish enqueueing even thoug= h it already has nothing to do at that time. It seems to me that even if we r= emove the public prod_tail structure, the enqueue operation is still able to= work. Because each core has known the exact enqueue position from its priva= te prod_head and prod_next. In another word, we just need to assure the corr= ectness of per core pointer and leave the rest of the enqueue work to that p= articular core. Those per core pointers they never overlap according to the C= AS atomic operation, that is our assumption.

What d= o you reckon?

Regards,
Bob
= --Apple-Mail-7E3B52B6-16B3-43F3-A598-ADB5E7A041C8--