From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Roger Keith" Subject: Re: Bulk dequeue of packets and the returned values, question Date: Sun, 28 Sep 2014 23:06:17 +0000 Message-ID: References: <54288A70.9020902@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "VENKATESAN, NAMAKKAL" Return-path: In-Reply-To: <54288A70.9020902-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Content-Language: en-US Content-ID: 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" 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