From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Harry van Haaren <harry.van.haaren@intel.com>, <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD
Date: Tue, 22 Nov 2016 01:48:37 +0530 [thread overview]
Message-ID: <20161121201837.GA12762@svelivela-lt.caveonetworks.com> (raw)
In-Reply-To: <20161121094856.GA16124@bricha3-MOBL3.ger.corp.intel.com>
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
>
> /Bruce
next prev parent reply other threads:[~2016-11-21 20:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 18:00 Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 1/7] eventdev: header and implementation Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 2/7] eventdev: makefiles Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 3/7] event/sw: software eventdev implementation Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 4/7] event/sw: makefiles and config Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 5/7] test/eventdev: unit and functional tests Harry van Haaren
2016-11-23 3:32 ` Jerin Jacob
2016-11-16 18:00 ` [dpdk-dev] [PATCH 6/7] test/eventdev: unit func makefiles Harry van Haaren
2016-11-16 18:00 ` [dpdk-dev] [PATCH 7/7] examples/eventdev_pipeline: adding example Harry van Haaren
2016-11-22 6:02 ` Jerin Jacob
2016-11-22 14:04 ` Richardson, Bruce
2016-11-23 0:30 ` Jerin Jacob
2016-11-16 20:19 ` [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD Jerin Jacob
2016-11-17 10:05 ` Bruce Richardson
2016-11-18 22:23 ` Jerin Jacob
2016-11-21 9:48 ` Bruce Richardson
2016-11-21 20:18 ` Jerin Jacob [this message]
2016-11-22 14:05 ` Richardson, Bruce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161121201837.GA12762@svelivela-lt.caveonetworks.com \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).