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 D1083A0C43; Thu, 15 Jul 2021 12:01:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B73A94014D; Thu, 15 Jul 2021 12:01:04 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id EBEC740143 for ; Thu, 15 Jul 2021 12:01:02 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10045"; a="210502748" X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="210502748" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2021 03:01:00 -0700 X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="489188612" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.5.22]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Jul 2021 03:00:55 -0700 Date: Thu, 15 Jul 2021 11:00:52 +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 03:19:55PM +0530, Jerin Jacob wrote: > On Thu, Jul 15, 2021 at 1:55 PM Bruce Richardson > wrote: > > > > 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? > > Agree. > > > > > 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 lets at > > least keep error count. > > +1 to keep submitted_count, completed_count, and fail count. > > enqueue count can be move to xstat if it is supported by drivers. > Also since drivers are returning, 0-2^16 monotonically incrementing counter , > even applications can track the enqueue count if needed without the driver > support. > Agreed. Let's just stick to 3 basic stats. /Bruce