> -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Monday, November 21, 2016 8:19 PM > To: Richardson, Bruce <bruce.richardson at intel.com> > Cc: Van Haaren, Harry <harry.van.haaren at intel.com>; dev at 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
