From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Richardson, Bruce" Subject: Re: [RFC PATCH 0/7] RFC: EventDev Software PMD Date: Tue, 22 Nov 2016 14:05:33 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B035B4D837@IRSMSX103.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> <20161121094856.GA16124@bricha3-MOBL3.ger.corp.intel.com> <20161121201837.GA12762@svelivela-lt.caveonetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Van Haaren, Harry" , "dev@dpdk.org" To: Jerin Jacob Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 1944B567A for ; Tue, 22 Nov 2016 15:05:38 +0100 (CET) In-Reply-To: <20161121201837.GA12762@svelivela-lt.caveonetworks.com> Content-Language: en-US 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" > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Monday, November 21, 2016 8:19 PM > To: Richardson, Bruce > Cc: Van Haaren, Harry ; dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD >=20 > 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. >=20 > 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. >=20 > Jerin >=20 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. /Bruce