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
