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 E6B5D41CEC; Mon, 20 Feb 2023 14:05:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EA4D43037; Mon, 20 Feb 2023 14:05:28 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 2E9BB40395 for ; Mon, 20 Feb 2023 14:05:27 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 76EEC3200D5A; Mon, 20 Feb 2023 08:05:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 20 Feb 2023 08:05:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1676898325; x= 1676984725; bh=nec1PmnT+ctDcLcyVb6aWd9abzrODLOmo3OeJDUneyI=; b=S QBphW5VuWgfvuwv63OkJ3nnO0F3twpmDKZADVh2eavanjwKjDijV8NzuHZ0at00u NXC28p8Cm3A+d9bVXUSSEVRmtjWlOUxIV9j9cG21WmMTWatE1Opb8cYgw2BlpEAg XzO3HlWDNO4l5Zn2fW2WDKUW4NFE8XJq9S8V1jFoDsz1fnoY8KwJKqzW0ts0J5qZ rNYHVij35Ch8OR7uVrrGWL/SwbK9x3oR8Ql9PlVnwmPgFdFfsWdYtDQQJJCmrdD8 IxAYI+gProO2c+AF3zsDZpV+KFh888Y7McY5SS3wJ8brS24vrPQvSgyLOoQDRjkp V3D/s3hj60dKBGKo/9Kyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676898325; x= 1676984725; bh=nec1PmnT+ctDcLcyVb6aWd9abzrODLOmo3OeJDUneyI=; b=s MVuqByGB2xh2crwcgbC9Vzv9Xhiky9o2yIMkua2x3vY7jyOM9rYxgYSoVhEFIUS8 hQajiSTGJ0UCfHB0IkyZoEZqMHxvmdFdFZ0Afgi1Rt5KFDhhNTqlZoW71j9wd8D7 WbcjCq+IqIGC8JH8kW73M+M/smCNzZbiOLBbHdb9emab75OSuBhfaUba4LkdE2+D IR92/d2YGEgunigXElVwf1GPB7OMBNayDpGE7gOxC9Sm82NGSObL2XNq98s0QO2s 2PDUWFB8jRFdG3PhcqotOl4MGqvG/FVW+m6p1jfYEbG2s9x71SN2kSbyBckw5DLG PnbrIIMxylp2B+ljECbfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejhedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 20 Feb 2023 08:05:23 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , Dongdong Liu , fengchengwen Cc: dev@dpdk.org, Ferruh Yigit , andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, ciara.power@intel.com, kevin.laatz@intel.com, david.marchand@redhat.com Subject: Re: [PATCH v5 2/2] ethdev: support xstats reset telemetry command Date: Mon, 20 Feb 2023 14:05:21 +0100 Message-ID: <12802674.ZYm5mLc6kN@thomas> In-Reply-To: <4ba214e6-6e9c-a527-0027-9f98b1fec537@huawei.com> References: <20221219090723.29356-1-fengchengwen@huawei.com> <4ba214e6-6e9c-a527-0027-9f98b1fec537@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 17/02/2023 10:44, fengchengwen: > On 2023/2/16 20:54, Bruce Richardson wrote: > > On Thu, Feb 16, 2023 at 08:42:34PM +0800, fengchengwen wrote: > >> On 2023/2/16 20:06, Ferruh Yigit wrote: > >>> On 2/16/2023 11:53 AM, fengchengwen wrote: > >>>> On 2023/2/15 11:19, Dongdong Liu wrote: > >>>>> Hi Chengwen > >>>>> > >>>>> On 2023/2/9 10:32, Chengwen Feng wrote: > >>>>>> The xstats reset is useful for debugging, so add it to the ethdev > >>>>>> telemetry command lists. > >>>>>> > >>>>>> Signed-off-by: Chengwen Feng > >>>>> This patch looks good, so > >>>>> Reviewed-by: Dongdong Liu > >>>>> > >>>>> A minior question > >>>>> Do we need to support stats reset ? > >>>> > >>>> Stats is contained by xstats, and future direction I think is xstats. > >>>> So I think we don't need support stats reset. > >>>> > >>> > >>> I have similar question with Dongdong, readonly values are safe for > >>> telemetry, but modifying data can be more tricky since we don't have > >>> locking in ethdev APIs, this can cause concurrency issues. > >> > >> Yes, it indeed has concurrency issues. > >> > >>> > >>> Overall do we want telemetry go that way and become something that > >>> alters ethdev data/config? > >> > >> There are at least two part of data: config and status. > >> For stats (which belong status data) could help for debugging, I think it's acceptable. > >> > >> As for concurrency issues. People should know what to do and when to do, just like > >> the don't invoke config API (e.g. dev_configure/dev_start/...) concurrency. > >> > > While this is probably ok for now, I think in next release we should look > > to add some sort of support for locking for destructive ops in a future > > release. For example, we could: > > > > 1. Add support for marking a callback as "destructive" and only allow it to > > be called if only one connection is present or > > > > 2. Make it possible for callbacks to query the number of connections so > > that the callback itself is non-destructive in more than one connection is > > open. > > > > [Both of these will require locking support so that new connections aren't > > openned when the callback is in-flight!] > > Except telemetry, the application may have other console could execute DPDK API. > So I think trying to keep it simple, it's up to the user to invoke. No, the user should not be responsible for concurrency issues. We can ask the app developper to take care, but not to the user who has no control on what happens in the app. On a more general note, I feel the expansion of telemetry is not controlled enough. I would like to stop on adding more telemetry until we have a clear guideline about what is telemetry for and how to use it.