From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC PATCH 0/7] RFC: EventDev Software PMD Date: Sat, 19 Nov 2016 03:53:25 +0530 Message-ID: <20161118222325.GA13345@localhost.localdomain> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Harry van Haaren , To: Bruce Richardson Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0051.outbound.protection.outlook.com [104.47.38.51]) by dpdk.org (Postfix) with ESMTP id C15E8558B for ; Fri, 18 Nov 2016 23:23:33 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161117100507.GA67928@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 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