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 BFEB7A0501; Fri, 8 Apr 2022 12:33:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9B1634067E; Fri, 8 Apr 2022 12:33:32 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 2A63B4003F for ; Fri, 8 Apr 2022 12:33:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649414011; x=1680950011; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3iV7EfD75ub3WnmIp5D9tkQVRNNc4NleSW/RjGZafs4=; b=F0aWsLCEQNAMSZNzxStkOjDetMPj5ZxWS+adKSdp7QclTtXfpQE31M3H rYU663hkfvAD2sL3CZwUQqiZWckw/ao/s5aU1m7N8vb1YjTvWFPvQITYp UkWCISz56N+PkXW5GUtx4l7nG1BTduAT3DnBOkpIDaSbW/3QramsqW+8h BSby3rYBRVGh3LrVq5weaI+Ox/dzbb1GAc4cdSHNAE5qUfMzyh24w3qAQ h9j1rI+9n2Yqo8qQyBt+97o4e+RgBo+cuy9g3U3rOWvFApufbwvAZjLMF kbIzKvu5GIECxje5GG5H9mwwxVXBaASuE8KtiAOCD2qNCty/wzoWISkFH A==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="322251244" X-IronPort-AV: E=Sophos;i="5.90,244,1643702400"; d="scan'208";a="322251244" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 03:33:15 -0700 X-IronPort-AV: E=Sophos;i="5.90,244,1643702400"; d="scan'208";a="571444240" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.224.53]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 08 Apr 2022 03:33:14 -0700 Date: Fri, 8 Apr 2022 11:33:11 +0100 From: Bruce Richardson To: Robin Zhang Cc: dev@dpdk.org, qiming.yang@intel.com, qi.z.zhang@intel.com, stevex.yang@intel.com Subject: Re: [PATCH v2] common/sff_module: add telemetry command to dump module EEPROM Message-ID: References: <20220215101853.919735-1-robinx.zhang@intel.com> <20220408102330.774749-1-robinx.zhang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220408102330.774749-1-robinx.zhang@intel.com> 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 Fri, Apr 08, 2022 at 10:23:30AM +0000, Robin Zhang wrote: > This patch introduce a new telemetry command '/sff_module/info' > to dump format module EEPROM information. > > The format support for SFP(Small Formfactor Pluggable)/SFP+ > /QSFP+(Quad Small Formfactor Pluggable)/QSFP28 modules based on > SFF(Small Form Factor) Committee specifications > SFF-8079/SFF-8472/SFF-8024/SFF-8636. > > Signed-off-by: Robin Zhang > --- > > v2: > - Redesign the dump function as a telemetry command, so that the EEPROM > information can be used by other app. > > - The usage like this: > > Launch the primary application with telemetry: > Take testpmd as example: ./app/dpdk-testpmd > > Then launch the telemetry client script: > ./usertools/dpdk-telemetry.py > > In telemetry client run command: > --> /sff_module/info, > > Both primary application and telemetry client will show the formated > module EEPROM information. > > drivers/common/meson.build | 1 + > drivers/common/sff_module/meson.build | 16 + > drivers/common/sff_module/sff_8079.c | 672 ++++++++++++++ > drivers/common/sff_module/sff_8472.c | 301 ++++++ > drivers/common/sff_module/sff_8636.c | 1004 +++++++++++++++++++++ > drivers/common/sff_module/sff_8636.h | 592 ++++++++++++ > drivers/common/sff_module/sff_common.c | 415 +++++++++ > drivers/common/sff_module/sff_common.h | 192 ++++ > drivers/common/sff_module/sff_telemetry.c | 142 +++ > drivers/common/sff_module/sff_telemetry.h | 41 + > drivers/common/sff_module/version.map | 9 + > 11 files changed, 3385 insertions(+) > create mode 100644 drivers/common/sff_module/meson.build > create mode 100644 drivers/common/sff_module/sff_8079.c > create mode 100644 drivers/common/sff_module/sff_8472.c > create mode 100644 drivers/common/sff_module/sff_8636.c > create mode 100644 drivers/common/sff_module/sff_8636.h > create mode 100644 drivers/common/sff_module/sff_common.c > create mode 100644 drivers/common/sff_module/sff_common.h > create mode 100644 drivers/common/sff_module/sff_telemetry.c > create mode 100644 drivers/common/sff_module/sff_telemetry.h > create mode 100644 drivers/common/sff_module/version.map > Is this is whole new driver just to provide telemetry dumps of SFP information? I can understand the problem somewhat - though I am in some doubt that telemetry is the best way to expose this information - but creating a new driver seems the wrong approach here. SFPs are for NIC devices, so why isn't this available in a common API such as ethdev? /Bruce