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 4127542DC0; Mon, 3 Jul 2023 09:20:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30D0F410DC; Mon, 3 Jul 2023 09:20:19 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 3BD63410DC for ; Mon, 3 Jul 2023 09:20:18 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 66D225C031F; Mon, 3 Jul 2023 03:20:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 03 Jul 2023 03:20:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type: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=fm2; t= 1688368817; x=1688455217; bh=kljnDkrvwkPkPVtxSRmQLQnXsKS2TOzU8YS WFwYD1uA=; b=ecFlEVGiWJ1pGW/TFElUaR4kvJ6P1S91tX8Y+hvLISxinFMDcoI 7iy/PewrO0yXOlPQj86RZCNVISKpE8p/x7wsWCYKOhLjw8ZldleWG29ScQ7Un1k9 io+ENXTIYcmmPnJ8mM5LdYqg9C8Flz96lNdk59SXr3ZFTc/8YRMa2X3GiQkoJLMJ gcusXa3NrZA1lOQgiAmPKs/cNxzyWxFtiE0GHldw1F191vvw4dPBQror0DDQ16VU Z3qJkbjbqyTxN4HzfdRIE+C7e1/GiXCCn2+KKsgVFcxbMozRaA6jOkxnvoIQnnc3 c0aIwSzNA/Au4tRmIgrgoL+oMhF4mvDmWvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type: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=fm2; t= 1688368817; x=1688455217; bh=kljnDkrvwkPkPVtxSRmQLQnXsKS2TOzU8YS WFwYD1uA=; b=INCft7Ly4XiZWeuAWUJxPSB9feYx+lE588G/pSNVxQ/ESGLIQ6o pAJfZn+iUX8/aydTp/OtxRUUPgLAhIVY4L0afh2nH+rpTA4Jma8k+dgfZ+JqBdzl 9uWuduhQOdy5Z7hNCmj/JojiYTCbXCPhcwRGAY2VQJo/wchPUHGHAXnQVPPJATrj GuwOW9RCTx2hJNv3gUV95nqpPhAcQLCfowLcoL3nxPhv9mrfP7t+0GyjuVoKe/v7 jaFgcPbBorznsT73b4qpDBNhaJPxD+UD+9YLNX0QNrHslll7HtALD+kOumjP3wdx yQUGUgFPgwg7z2tSyBjk1Iszlf8KQUcgdiA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddugdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Jul 2023 03:20:15 -0400 (EDT) From: Thomas Monjalon To: Dongdong Liu , fengchengwen Cc: Bruce Richardson , dev@dpdk.org, Ferruh Yigit , andrew.rybchenko@oktetlabs.ru, 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, 03 Jul 2023 09:20:13 +0200 Message-ID: <18761354.fAMKPKieAE@thomas> In-Reply-To: References: <20221219090723.29356-1-fengchengwen@huawei.com> <12802674.ZYm5mLc6kN@thomas> 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 03/07/2023 05:58, fengchengwen: > > On 2023/2/20 21:05, Thomas Monjalon wrote: > > 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. > > Hi Thomas, > > Should this be discussed on TB? What would be your question exactly?