From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id C55649A9F for ; Fri, 13 Mar 2015 15:50:06 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 13 Mar 2015 07:50:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,395,1422950400"; d="scan'208";a="679698887" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.28]) by fmsmga001.fm.intel.com with SMTP; 13 Mar 2015 07:50:03 -0700 Received: by (sSMTP sendmail emulation); Fri, 13 Mar 2015 14:50:03 +0025 Date: Fri, 13 Mar 2015 14:50:03 +0000 From: Bruce Richardson To: Neil Horman Message-ID: <20150313145002.GA11352@bricha3-MOBL3> References: <1426179268-22164-1-git-send-email-john.mcnamara@intel.com> <20150312191540.GB15260@hmsreliant.think-freely.org> <20150313094133.GA5056@bricha3-MOBL3> <20150313134514.GC28191@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313134514.GC28191@hmsreliant.think-freely.org> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX callback 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: Fri, 13 Mar 2015 14:50:07 -0000 On Fri, Mar 13, 2015 at 09:45:14AM -0400, Neil Horman wrote: > On Fri, Mar 13, 2015 at 09:41:33AM +0000, Bruce Richardson wrote: > > On Thu, Mar 12, 2015 at 03:15:40PM -0400, Neil Horman wrote: > > > On Thu, Mar 12, 2015 at 04:54:27PM +0000, John McNamara wrote: > > > > > > > > This patch is a minor extension to the recent patchset for RX/TX callbacks > > > > based on feedback from users implementing solutions based on it. > > > > > > > > The patch adds a new parameter to the RX callback to pass in the number of > > > > available RX packets in addition to the number of dequeued packets. > > > > This provides the RX callback functions with additional information > > > > that can be used to decide how packets from a burst are handled. > > > > > > > > The TX callback doesn't require this additional parameter so the RX > > > > and TX callbacks no longer have the same function parameters. As such > > > > the single RX/TX callback has been refactored into two separate callbacks. > > > > > > > > Since this is an API change we hope it can be included in 2.0.0 to avoid > > > > changing the API in a subsequent release. > > > > > > > > > > > > John McNamara (1): > > > > ethdev: added additional packet count parameter to RX callbacks > > > > > > > > examples/rxtx_callbacks/main.c | 3 +- > > > > lib/librte_ether/rte_ethdev.c | 8 ++-- > > > > lib/librte_ether/rte_ethdev.h | 74 ++++++++++++++++++++++++++-------------- > > > > 3 files changed, 54 insertions(+), 31 deletions(-) > > > > > > > > -- > > > > 1.7.4.1 > > > > > > > > > > > > > > > > > Well, we're well past the new feature phase of this cycle, so I would say NACK. > > > I would also suggest that you don't need to modify ABI to accomodate this > > > feature. Instead just document the pkts array to be terminated by a reserved > > > value, so that the callback can determine its size dynamically. You could > > > alternatively create a new api call that allows you to retrieve that information > > > from the context of the callback. > > > > > > Neil > > > > > > > Yes, I would agree we are past the new feature phase. However, given that we > > are making a change to the API, and a fairly small change too - adding one extra > > parameter - we think that the benefit of including this now outweighs any risk > > of merging the patch. It seems a bit crazy to ship a release with a new API and > > then immediately change the API straight after release. Is it not better to > > take the received feedback on the API and fix/improve it pre-release before it > > gets set-in-stone? > > > > /Bruce > > > > > > See above, the API doesn't need to change at all to accomodate this as far as I > can see. > > Neil Yes, there are alternative ways to see about accomplishing the same thing, but they are not nearly as clear as adding in the extra param. That's why we'd like to see this change go in before release, if possible. If it doesn't make 2.0 I'd like to see it in 2.1, but at the cost of having an API change and the additional versionning and deprecation that ensues. Regards, /Bruce