From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: Bulk dequeue of packets and the returned values, question Date: Mon, 29 Sep 2014 13:10:22 +0100 Message-ID: <20140929121022.GH12072@BRICHA3-MOBL> References: <54288A70.9020902@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Wiles, Roger Keith" Return-path: Content-Disposition: inline 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" 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 b= e fixed or variable. On fixed < 0 on error is returned and 0 if successf= ul. 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 erro= r and >=3D 0 on success. Which means a dequeue from a fixed ring would re= turn only =E2=80=99requested size n=E2=80=99 or < 0 if you error off the = 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 f= unctions. The original functions that were implemented for the ring were = only the bulk functions (i.e. FIXED). They would return exactly the numbe= r of items requested for dequeue (0 if success, negative if error), and n= ot 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 quit= e a number of deployments of DPDK in the field using the legacy ring func= tions. Therefore we made the decision to keep the legacy behavior intact = & not impacting deployed code - and merging the burst functions into the = code. Given that there was no "versioning" of the API/ABI in those releas= es :). >=20 > I see why the code is this way. If the developers used =E2=80=98if ( re= t =3D=3D 0 ) { /* do something */ }=E2=80=99 then it would break if it re= turned a positive value on success. I would expect the normal behavior to= be =E2=80=98if ( ret < 0 ) { /* error case */ }=E2=80=99 and fall thru f= or the success case. I would love to change the code to just return <0 on= error or >=3D 0 on success. 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 mobi= le 972-213-5533 >=20 > Keith Wiles, Principal Technologist with CTO office, Wind River mobile = 972-213-5533 >=20 Since we are looking at making considerable ABI changes in this release a= nd=20 (hopefully) also looking to version our ABI going forward, I would be in=20 favour of making any changes to these APIs in this current release if=20 possible. While the current behaviour makes sense for historical reason, = I=20 think an overall change to the behaviour as Keith describes would be more= =20 sensible long-term.=20 (Also to note my previous suggestion about upping the major version to 2.= 0=20 if we continue to increase the number of ABI/API changes in this release.= =20 Anyone else any thoughts on that?) /Bruce