From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id BF2F05902 for ; Mon, 29 Sep 2014 00:29:52 +0200 (CEST) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XYN4d-0007Lq-Kf; Sun, 28 Sep 2014 18:36:24 -0400 Date: Sun, 28 Sep 2014 18:36:08 -0400 From: Neil Horman To: "Venkatesan, Venky" Message-ID: <20140928223607.GA4810@localhost.localdomain> References: <54288A70.9020902@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54288A70.9020902@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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:29:53 -0000 On Sun, Sep 28, 2014 at 03:23:44PM -0700, Venkatesan, Venky wrote: > Keith, > > 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? > > > >If these are true then why not have the routines return < 0 on error and >= 0 on success. Which means a dequeue from a fixed ring would return only ’requested size n’ 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. > > > >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 were > only the bulk functions (i.e. FIXED). They would return exactly the number > of items requested for dequeue (0 if success, negative if error), and not > return any if the required number were not available. > > 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 functions. > 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 :). > 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