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

Bruce Richardson bruce.richardson at intel.com
Fri Mar 13 15:50:03 CET 2015


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



More information about the dev mailing list