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

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Monday, November 21, 2016 8:19 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD
> 
> 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.
> 
> Jerin
> 

Yes, that can work. Many of the unit tests we are looking at are likely
specific to our software implementation, so we may end up doing a separate
sw-eventdev specific unit test set, as well as a general eventdev set.

/Bruce