From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37E41A0C43; Thu, 15 Jul 2021 10:25:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9E33B40143; Thu, 15 Jul 2021 10:25:30 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id B9EEB40140 for ; Thu, 15 Jul 2021 10:25:28 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10045"; a="232325182" X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="232325182" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2021 01:25:27 -0700 X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="652716681" Received: from ccarthy-mobl1.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.5.222]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Jul 2021 01:25:24 -0700 Date: Thu, 15 Jul 2021 09:25:21 +0100 From: Bruce Richardson To: Jerin Jacob Cc: fengchengwen , Thomas Monjalon , Ferruh Yigit , Jerin Jacob , Andrew Rybchenko , dpdk-dev , Morten =?iso-8859-1?Q?Br=F8rup?= , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor , "Ananyev, Konstantin" Message-ID: References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626179263-14645-1-git-send-email-fengchengwen@huawei.com> <02340ac8-9d09-15e8-3969-1850f08e5831@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3] dmadev: introduce DMA device library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jul 15, 2021 at 12:14:05PM +0530, Jerin Jacob wrote: > On Tue, Jul 13, 2021 at 7:08 PM Bruce Richardson > wrote: > > > > On Tue, Jul 13, 2021 at 09:06:39PM +0800, fengchengwen wrote: > > > > 4. COMMENT:> + uint64_t reserved[4]; /**< Reserved for future > > > fields */ > > > > +}; > > > Please add the capability for each counter in info structure as one > > > device may support all the counters. > > > > > > REPLY: This is a statistics function. If this function is not supported, > > > then do not need to implement the stats ops function. Also could to set > > > the unimplemented ones to zero. > > > > > +1 > > The stats functions should be a minimum set that is supported by all > > drivers. Each of these stats can be easily tracked by software if HW > > support for it is not available, so I agree that we should not have each > > stat as a capability. > > In our current HW, submitted_count and completed_count offloaded to HW. > In addition to that, we have a provision for getting stats for bytes > copied.( We can make it as xstat, if other drivers won't support) > > our plan is to use enqueued_count and completed_fail_count in SW under > condition compilation flags or another scheme as it is in fastpath. > > If we are not planning to add capability, IMO, we need to update the > documentation, > like unimplemented counters will return zero. But there is the > question of how to differentiate between > unimplemented vs genuine zero value. IMO, we can update the doc for > this case as well or > add capability. > While we could add capabilities for stats, I'd really rather not. Let's just get an agreed upon minimum set. Seems like submitted and completed are fine for all, which just leaves two to discuss for an in/out decision. Jerin, can fail count be kept without conditional compilation, perhaps, because it should not be touched in the fastpath but just on error legs? For enqueued_count, in our driver I was just going to track the difference between last doorbell and this one - which we would be tracking anyway, or could compute very easily by saving last doorbell counter - and add that to the submitted count when stats are requested. That would again ensure no fastpath impact bar perhaps storing one additional variable (old DB) per burst. If that is felt too cumbersome, I think we can drop it, but let's at least keep error count. Thanks, /Bruce