From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: Bulk dequeue of packets and the returned values, question Date: Sun, 28 Sep 2014 18:36:08 -0400 Message-ID: <20140928223607.GA4810@localhost.localdomain> 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: "Venkatesan, Venky" Return-path: Content-Disposition: inline In-Reply-To: <54288A70.9020902-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 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 03:23:44PM -0700, 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 = 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 z= ero in the variable case, correct? > > > >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 retu= rn 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 r= ing for the fixed ring case. > > > >Does this make sense to anyone? > It won't make sense unless you're aware of the history behind these > functions. The original functions that were implemented for the ring we= re > only the bulk functions (i.e. FIXED). They would return exactly the num= ber > 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 quite a > number of deployments of DPDK in the field using the legacy ring functi= ons. > 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 releases := ). >=20 Hehe :) Yes, API versioning would be a great benefit to this sort of problem. If= only there were a patchset available to create that ability ;) Neil