Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Neil Horman <nhorman@tuxdriver.com>]

On Fri, Mar 13, 2015 at 02:50:03PM +0000, Bruce Richardson wrote:
> 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.
> 
Plese set asside the ABI issue for a moment.  I get that you're trying to get it
in prior to needing to version it.  Thats not the argument.  The argument is how
best to codify the new information you want to express in the callback.  For
this specific case, I think there are better ways to do this than to just
blindly add a new parameter.  Encoding the array size implicitly with a
terminating marker lets you use this equally well with the tx and rx callbacks
(should you ever need it on the latter), and isn't uncommon to do at all.  It
also lets you avoid the odd bugs that arise should the caller ever mis-encode
the array length such that it doesn't match the actual array size.

Using additional context sensitive functions are also nice, because they are
additive without being ABI breaking.  That is to say, in the future, if you want
to export more information to a callback you can do so by adding an API call
that simply didnt' exist before.  Thats a nice feature to be able to support.

Just adding more parameters isn't the only (nor in my view) the more flexible
way to do this

Neil

> Regards,
> /Bruce
> 
>