From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by dpdk.org (Postfix) with ESMTP id 0CF5E6893 for ; Mon, 29 Sep 2014 16:51:25 +0200 (CEST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.9/8.14.5) with ESMTP id s8TEw0jk003851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Sep 2014 07:58:00 -0700 (PDT) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.18]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 07:57:59 -0700 From: "Wiles, Roger Keith" To: "ANANYEV, KONSTANTIN" Thread-Topic: [dpdk-dev] Bulk dequeue of packets and the returned values, question Thread-Index: AQHP2950iN7qDmkAiEGUOHWML8svb5wYf9oAgAApRoA= Date: Mon, 29 Sep 2014 14:57:59 +0000 Message-ID: <4FD9B9E1-CB15-4230-A2B8-CC13B672B139@windriver.com> References: <54288A70.9020902@intel.com> <20140929121022.GH12072@BRICHA3-MOBL> <2601191342CEEE43887BDE71AB97725821387594@IRSMSX104.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725821387594@IRSMSX104.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.40.166] Content-Type: text/plain; charset="Windows-1252" Content-ID: <869B06DA4602C4439CD735BA8CB8CC59@local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Bulk dequeue of packets and the returned values, question 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: Mon, 29 Sep 2014 14:51:26 -0000 On Sep 29, 2014, at 7:30 AM, Ananyev, Konstantin wrote: >=20 >=20 >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson >> Sent: Monday, September 29, 2014 1:10 PM >> To: Wiles, Roger Keith (Wind River) >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] Bulk dequeue of packets and the returned values,= question >>=20 >> On Sun, Sep 28, 2014 at 11:06:17PM +0000, Wiles, Roger Keith wrote: >>> Thanks Venky, >>> On Sep 28, 2014, at 5:23 PM, Venkatesan, Venky wrote: >>>=20 >>>> Keith, >>>>=20 >>>> On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote: >>>>> I am also looking at the bulk dequeue routines, which the ring can be= fixed or variable. On fixed < 0 on error is returned and 0 if >> successful. On a variable ring < 0 on error or n on success, but I think= n can be zero in the variable case, correct? >>>>>=20 >>>>> If these are true then why not have the routines return < 0 on error= and >=3D 0 on success. Which means a dequeue from a fixed >> ring would return only =92requested size n=92 or < 0 if you error off th= e 0 case. The 0 case could be OK, if you allow zero to be return on a >> empty ring for the fixed ring case. >>>>>=20 >>>>> Does this make sense to anyone? >>>> It won't make sense unless you're aware of the history behind these fu= nctions. The original functions that were implemented for >> the ring were only the bulk functions (i.e. FIXED). They would return ex= actly the number of items requested for dequeue (0 if success, >> negative if error), and not return any if the required number were not a= vailable. >>>>=20 >>>> The burst (i.e. VARIABLE) functions came in much later (think it was r= 1.3 where we introduced them), and by that time, there were >> already quite a number of deployments of DPDK in the field using the leg= acy ring functions. Therefore we made the decision to keep >> the legacy behavior intact & not impacting deployed code - and merging t= he burst functions into the code. Given that there was no >> "versioning" of the API/ABI in those releases :). >>>=20 >>> I see why the code is this way. If the developers used =91if ( ret =3D= =3D 0 ) { /* do something */ }=92 then it would break if it returned a >> positive value on success. I would expect the normal behavior to be =91i= f ( ret < 0 ) { /* error case */ }=92 and fall thru for the success case. I >> would love to change the code to just return <0 on error or >=3D 0 on su= ccess. I wonder how many customers code would break >> changing the code to do just just the two steps. I think it will remove = some code in a couple places that were testing for FIXED or >> VARIABLE? >>>>=20 >>>> Hope that helps. >>>> -Venky >>>>=20 >>>>>=20 >>>>> Thanks >>>>> ++Keith >>>>>=20 >>>>> Keith Wiles, Principal Technologist with CTO office, Wind River mobil= e 972-213-5533 >>>=20 >>> Keith Wiles, Principal Technologist with CTO office, Wind River mobile = 972-213-5533 >>>=20 >>=20 >> Since we are looking at making considerable ABI changes in this release = and >> (hopefully) also looking to version our ABI going forward, I would be in >> favour of making any changes to these APIs in this current release if >> possible. While the current behaviour makes sense for historical reason,= I >> think an overall change to the behaviour as Keith describes would be mor= e >> sensible long-term. >=20 > It is doable, I suppose, but might become quite messy: > Don't know how many people are using rte_ring_dequeue_bulk() all over th= e place. > I suspect quite a lot. > From other side - what the real gain we'll have from it? > I don't see much so far. > Konstantin >=20 I see two possible gains one is a consistent return method for Fixed/Variab= le and some code reduction in a few places. Let me see if I can create a pa= tch we can review and see if it seems reasonable. >>=20 >> (Also to note my previous suggestion about upping the major version to 2= .0 >> if we continue to increase the number of ABI/API changes in this release= . >> Anyone else any thoughts on that?) Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-= 213-5533