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

[Neil Horman]

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