From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC PATCH 0/7] RFC: EventDev Software PMD Date: Tue, 22 Nov 2016 01:48:37 +0530 Message-ID: <20161121201837.GA12762@svelivela-lt.caveonetworks.com> References: <1479319207-130646-1-git-send-email-harry.van.haaren@intel.com> <20161116201924.GA32292@svelivela-lt.caveonetworks.com> <20161117100507.GA67928@bricha3-MOBL3.ger.corp.intel.com> <20161118222325.GA13345@localhost.localdomain> <20161121094856.GA16124@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Harry van Haaren , To: Bruce Richardson Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0071.outbound.protection.outlook.com [104.47.42.71]) by dpdk.org (Postfix) with ESMTP id C3FD429D6 for ; Mon, 21 Nov 2016 21:18:45 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161121094856.GA16124@bricha3-MOBL3.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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