[dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD

Jerin Jacob jerin.jacob at caviumnetworks.com
Mon Nov 21 21:18:37 CET 2016

On Mon, Nov 21, 2016 at 09:48:56AM +0000, Bruce Richardson wrote:
> On Sat, Nov 19, 2016 at 03:53:25AM +0530, Jerin Jacob wrote:
> > On Thu, Nov 17, 2016 at 10:05:07AM +0000, Bruce Richardson wrote:
> > > > 2) device stats API can be based on capability, HW implementations may not
> > > > support all the stats
> > > 
> > > Yes, this is something we were thinking about. It would be nice if we
> > > could at least come up with a common set of stats - maybe even ones
> > > tracked at an eventdev API level, e.g. nb enqueues/dequeues. As well as
> > > that, we think the idea of an xstats API, like in ethdev, might work
> > > well. For our software implementation, having visibility into the
> > > scheduler behaviour can be important, so we'd like a way to report out
> > > things like internal queue depths etc.
> > >
> > 
> > Since these are not very generic hardware, I am not sure how much sense
> > to have generic stats API. But, Something similar to ethdev's xstat(any capability based)
> > the scheme works well. Look forward to seeing API proposal with common code.
> > 
> > Jerin
> > 
> Well, to start off with, some stats that could be tracked at the API
> level could be common. What about counts of number of enqueues and
> dequeues?
> I suppose the other way we can look at this is: once we get a few
> implementations of the interface, we can look at the provided xstats
> values from each one, and see if there is anything common between them.

That makes more sense to me as we don't have proposed counts. I think,
Then we should not use stats for functional tests as proposed. We could
verify the functional test by embedding some value in event object on
enqueue and later check the same on dequeue kind of scheme.


> /Bruce

More information about the dev mailing list