From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 102322BC6 for ; Mon, 21 Nov 2016 10:49:02 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 21 Nov 2016 01:49:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,674,1473145200"; d="scan'208";a="193974538" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by fmsmga004.fm.intel.com with SMTP; 21 Nov 2016 01:49:00 -0800 Received: by (sSMTP sendmail emulation); Mon, 21 Nov 2016 09:48:56 +0000 Date: Mon, 21 Nov 2016 09:48:56 +0000 From: Bruce Richardson To: Jerin Jacob Cc: Harry van Haaren , dev@dpdk.org Message-ID: <20161121094856.GA16124@bricha3-MOBL3.ger.corp.intel.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118222325.GA13345@localhost.localdomain> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:49:04 -0000 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. /Bruce