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 1944B567A for ; Tue, 22 Nov 2016 15:05:38 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 22 Nov 2016 06:05:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,533,1473145200"; d="scan'208";a="1062792266" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 22 Nov 2016 06:05:35 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.91]) by IRSMSX104.ger.corp.intel.com ([169.254.5.52]) with mapi id 14.03.0248.002; Tue, 22 Nov 2016 14:05:34 +0000 From: "Richardson, Bruce" To: Jerin Jacob CC: "Van Haaren, Harry" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD Thread-Index: AQHSQDNgLtL4xzD4H0GNpvTJv4aN/KDcDQyAgADmsoCAAmCcgIAD5DIAgACv74CAASncAA== 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> In-Reply-To: <20161121201837.GA12762@svelivela-lt.caveonetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGQ3ZmUzMDctZGNjMy00Y2JlLWJmYWMtY2JmNGRmMDU4ZGI1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFBY1lpZFh3VDRnV1d2SUo3TmRXZmZaQXlxcld5bmJmRHhvaU11SUt6RDg9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 22 Nov 2016 14:05:39 -0000 > -----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