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 33610A00C5; Wed, 16 Feb 2022 11:02:50 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1939B410FF; Wed, 16 Feb 2022 11:02:50 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 7C14C410FB for ; Wed, 16 Feb 2022 11:02:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645005768; x=1676541768; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=LioRbkU7d+A66emozUwui3Q0uUK87V5UI9hWbn4r4bg=; b=eY4ntQrmwHHFLXAE9u01LigphzwQ5ZUvtPRiHRnOA1AwUVJ9vYBIqkls lDieY4RbE/JmWndEnrMVpjFArF5PZ2a6JGccbQmgwytKDjIxtLxAkIqQ+ r2HzciXr8xwGoiYMVgcj28s9azRhUe7CcpYaw0kHvRwQ04d2wQ8EyG1ZH hlXSw2Fw29BstpNE9SGqOSz8XD/sIsCwLgzWnPI+oivg/DZht9WQWWulX GdqpNlcjbRO46WYba/Gaq77/s0hCkV8HuVm9oTRnhIyvdYmJDwF6B+6CO 7gCIP53yK0bnlxsduKTzN2iGm2TwfSJebBUsUQaY8KT7hjU0mXTIFQmtb g==; X-IronPort-AV: E=McAfee;i="6200,9189,10259"; a="230530569" X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="230530569" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2022 02:02:47 -0800 X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="704239212" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.192]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Feb 2022 02:02:44 -0800 Date: Wed, 16 Feb 2022 10:02:41 +0000 From: Bruce Richardson To: David Marchand Cc: Thomas Monjalon , "Zhang, RobinX" , "Yigit, Ferruh" , dev , "Zhang, Qi Z" , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Guo, Junfeng" , "Yang, SteveX" , Ciara Power Subject: Re: [PATCH] app/testpmd: format dump information of module EEPROM Message-ID: References: <20220215101853.919735-1-robinx.zhang@intel.com> <1696182.K4a6FZZPjd@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Wed, Feb 16, 2022 at 10:41:43AM +0100, David Marchand wrote: > On Wed, Feb 16, 2022 at 10:31 AM Bruce Richardson > wrote: > > > > I see that we have other telemetry callbacks for stats, link status > > > > which might already have the issue. > > > > > > You mean there is no lock protection? Neither in the API, nor in > > > telemetry? > > > > > For reporting out stats or link status, I'm not sure a lock should ever > > be needed since both are just read-only operations. Therefore, I don't > > believe we have a general issue here. > > Ok, if you are sure about this for all drivers for stats and link status, > you can discard my comment. > No, I'm not 100% sure about it, but if any driver has issues with multiple threads reading stats simultaneously I would hope that that should be resolved at the driver level. Normally, one would expect read-only operations to be implicitly multi-thread safe, and I also see that the documentation on e.g. rte_eth_stats_get() makes no reference to needing locks or not being thread-safe. I note too, that any such issues would not be limited to telemetry only, but would also apply to pdump or any mechanism we would want to have for reading information about a running process. /Bruce