From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by dpdk.org (Postfix) with ESMTP id 104E71F7 for ; Mon, 29 Sep 2014 00:59:45 +0200 (CEST) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.9/8.14.5) with ESMTP id s8SN6IVK000952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 28 Sep 2014 16:06:18 -0700 (PDT) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.18]) by ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 16:06:17 -0700 From: "Wiles, Roger Keith" To: "VENKATESAN, NAMAKKAL" Thread-Topic: [dpdk-dev] Bulk dequeue of packets and the returned values, question Thread-Index: AQHP22rnwGvaAMxlYkGkN3DOZkPwJZwXoB8A Date: Sun, 28 Sep 2014 23:06:17 +0000 Message-ID: References: <54288A70.9020902@intel.com> In-Reply-To: <54288A70.9020902@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: 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: Sun, 28 Sep 2014 22:59:46 -0000 Thanks Venky, On Sep 28, 2014, at 5:23 PM, Venkatesan, Venky = wrote: > 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 fi= xed 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 an= d >=3D 0 on success. Which means a dequeue from a fixed ring would return o= nly =92requested size n=92 or < 0 if you error off the 0 case. The 0 case c= ould be OK, if you allow zero to be return on a empty ring for the fixed ri= ng case. >>=20 >> Does this make sense to anyone? > It won't make sense unless you're aware of the history behind these funct= ions. The original functions that were implemented for the ring were only t= he bulk functions (i.e. FIXED). They would return exactly the number of ite= ms requested for dequeue (0 if success, negative if error), and not return = any if the required number were not available. >=20 > The burst (i.e. VARIABLE) functions came in much later (think it was r1.3= where we introduced them), and by that time, there were already quite a nu= mber of deployments of DPDK in the field using the legacy ring functions. T= herefore we made the decision to keep the legacy behavior intact & not impa= cting deployed code - and merging the burst functions into the code. Given = that there was no "versioning" of the API/ABI in those releases :). 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 =91if ( 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 success. I wonde= r 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 t= esting for FIXED or VARIABLE? >=20 > Hope that helps. > -Venky >=20 >>=20 >> Thanks >> ++Keith >>=20 >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile 9= 72-213-5533 Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-= 213-5533