[dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD
bruce.richardson at intel.com
Tue Nov 22 15:05:33 CET 2016
> -----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.
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.
More information about the dev