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 783C4A00C5; Wed, 16 Feb 2022 10:31:01 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 04EF4410FB; Wed, 16 Feb 2022 10:31:01 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 2DAF3410F7 for ; Wed, 16 Feb 2022 10:30:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645003859; x=1676539859; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nNtsyhsShcNkXlljl7pjoIAXQcQp44dRihBp779/cMo=; b=DeFooFAxtzmy5TYpZQRbwN14q6D/tgLfynU8kvKsL8vj5VJUhNePZfaS A1+6Hlvd7zUW46lWoBfyo0p82Th41Jf9TYmReSGDbOG8FyKtDP6OvAoyd qPekjyz+fOIhTv7k8clkuVCP2aclQxvji6BRBbmwVoa6etXZKcMkiLIew EEmQUEirZRvoIOhHTNHCrVO+0zLTs7aPLYTYZya99fmaNUbfACQkY+qm+ 21AkzKa3QVLimHzIGXLeeEBqZn6Ey70LX/KJuCbgVBlq+Dqhy/W3zVx2v +CCXc22JH/Y2I4DjVJPXCLd94ypSo0SAPZCXxt3eMGQRSFghx68tUq+QJ w==; X-IronPort-AV: E=McAfee;i="6200,9189,10259"; a="250299359" X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="250299359" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2022 01:30:58 -0800 X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="625303632" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.192]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Feb 2022 01:30:55 -0800 Date: Wed, 16 Feb 2022 09:30:52 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: "Zhang, RobinX" , "Yigit, Ferruh" , dev@dpdk.org, "Zhang, Qi Z" , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Guo, Junfeng" , "Yang, SteveX" , David Marchand , ciara.power@intel.com 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: <1696182.K4a6FZZPjd@thomas> 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 09:45:33AM +0100, Thomas Monjalon wrote: > 16/02/2022 09:03, David Marchand: > > On Wed, Feb 16, 2022 at 3:27 AM Zhang, RobinX wrote: > > > The idea behind this is to monitor the quality of the link in the field during testpmd operations. > > > It is supported in Linux driver with ethtool command "ethtool -m xxx", but missing in DPDK. > > That's why the bifurcated model used by mlx drivers is so much valuable: > you can use such ethtool command while using DPDK. > > > > This feature is requested by customer 6WIND and we have been told this is highly important in production. > > > 6WIND also mentioned some other customers: NEC, EOLO and Open Systems. > > > Similar request also received from customer CheckPoint. > > > > > > > > What do you think to have this as a sample application? > > > > > > > > It can be in the directory app/ maybe. > > > > > > Base on the above background, I'm not sure if customer could accept this feature as a sample application. > > > > Rather than add this in testpmd or a sample app, does it make sense to > > provide this info as a telemetry command? > > This makes those status information available in any dpdk application. > > +1 > Production code should be in a DPDK library. > > > There is a "but" with this proposal. > > Existing applications might have been calling "eeprom" ethdev API > > already, and adding such a callback in telemetry could lead to > > concurrency issues. > > > > 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. /Bruce