From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <bruce.richardson@intel.com>
To: Robin Zhang <robinx.zhang@intel.com>
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: <YlAPZwaj7OdxBjsx@bricha3-MOBL.ger.corp.intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <robinx.zhang@intel.com>
> ---
> 
> 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,<port number>
> 
>   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