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 672A9A0C43; Thu, 15 Jul 2021 11:50:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4D3C4014D; Thu, 15 Jul 2021 11:50:23 +0200 (CEST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by mails.dpdk.org (Postfix) with ESMTP id 9A7EF40143 for ; Thu, 15 Jul 2021 11:50:22 +0200 (CEST) Received: by mail-il1-f176.google.com with SMTP id b6so4429195iln.12 for ; Thu, 15 Jul 2021 02:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vqu0/omiGFftlU4rki5HWLgoW0dPvdqqbDkq7JdPiGo=; b=DMRyYpL4w/M2EV5K/kdAJbEtETAn/gXvYJTnJ3m1c7keqPCBOu71JSsBf9NJMXdrJB Ak+IQ2N1AwTURZyqfydhCsk3/hMen7tqFA7qQCzKoi2eimXdVFMu83Olb1jJgJV4Zmzw DPrDlh1tdHHUgrIKvN73L2reTs+fzhtK//ZNL3ZZZ2Z5/lyMVS4v93pgNIDDxeuecOHJ Rm38HT/ba8U92est4oUUC5sVnv2HvpmsVEX1qOPe6Tyc9qkhQulaGgZ+mk0z0H3Vfc1x 2j8iQFezITGrndECYwhF+0dzvtjmL4+HS1Y5+k+m/ySLxERgaQVj2dpltGk7QDht19Ul 3sUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vqu0/omiGFftlU4rki5HWLgoW0dPvdqqbDkq7JdPiGo=; b=nhILbveoQ2GL4tIrQx2ILYYuKMPJve5ko/78UByWqdqMW5Ct6t4YmhEkZyE3TJooPQ izj7AmW9KO/UNHHk+hgCZNj++kPDtxZ/3wAj6CF5bQhmkWBItPK2SO2vYK/IW0jP8Xst gkvxhgAT4NaMH7qH0jBCPHlK/o2n8horGZ0vTLCFd157t1/6r8ZT0ffqOrMP1H5BZftD To8CwBOWAvnWpoJIY2CupfwiUIRmutIYX4qmr5ljGTr/Y8U9cupJLiIcOGD87UCwSFfM 3NjiYelE5d8BFuaviQoEKgDs3yIRMH4mhKg1cYeYUHo4xApaVF5km1YO1vKRWk1BNON6 Rw6Q== X-Gm-Message-State: AOAM533fNtQIooc8raeLT0l+CQS+8am+VQ3jqABjwIG9OOGlUNzxzE1x 03w7FTsgWDZYo3FJCDhwO9cs/UfLLUZDGr1qGrc= X-Google-Smtp-Source: ABdhPJzVlAvlY3mSRhYL9dca6MbCWJE0J7uLqMrBLfCbl6mtXJguy0PoW2bdlH9d/6yymkNPwwLGhPpclh6f6eD54D0= X-Received: by 2002:a92:d946:: with SMTP id l6mr2127352ilq.162.1626342621943; Thu, 15 Jul 2021 02:50:21 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Jul 2021 15:19:55 +0530 Message-ID: To: Bruce Richardson Cc: fengchengwen , Thomas Monjalon , Ferruh Yigit , Jerin Jacob , Andrew Rybchenko , dpdk-dev , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor , "Ananyev, Konstantin" Content-Type: text/plain; charset="UTF-8" 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 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. > > Thanks, > /Bruce