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 31435A0547; Fri, 23 Apr 2021 18:18:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A9AD2410E1; Fri, 23 Apr 2021 18:18:08 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 2890F410D8 for ; Fri, 23 Apr 2021 18:18:06 +0200 (CEST) IronPort-SDR: tAGzpPFY5XfgOS8a+u+bSj6/8tN8LFXU2YaBMLNqWzDqYs5ZgVqm4Le1MfUuH4uTnsMPeSXPqB Cn1sTvSsSrDw== X-IronPort-AV: E=McAfee;i="6200,9189,9963"; a="175578590" X-IronPort-AV: E=Sophos;i="5.82,246,1613462400"; d="scan'208";a="175578590" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 09:18:05 -0700 IronPort-SDR: DvKGRs6V9nUcB549n3NyYD5z37cxunlWxRHOSN5u3mRRWk1AGcZGwhfHVzXamyvfE4MP6Xz2DI 8r8o5odna4OA== X-IronPort-AV: E=Sophos;i="5.82,246,1613462400"; d="scan'208";a="464376739" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.255.228]) ([10.213.255.228]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 09:18:04 -0700 From: Ferruh Yigit To: Heinrich Kuhn , dev@dpdk.org References: <20210225114622.2431-1-heinrich.kuhn@netronome.com> <54de2177-d56c-2281-2e92-8603450a99c6@intel.com> X-User: ferruhy Message-ID: Date: Fri, 23 Apr 2021 17:18:00 +0100 MIME-Version: 1.0 In-Reply-To: <54de2177-d56c-2281-2e92-8603450a99c6@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] doc: fix nfp multiport syntax 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 Sender: "dev" On 3/1/2021 1:45 PM, Ferruh Yigit wrote: > On 2/25/2021 11:46 AM, Heinrich Kuhn wrote: >> From: "Chaoyong.He" >> >> 1. Fixup the suffix of the PCI ID to be consistent with the code. >> 2. Add specification of using MAC address to identify port. >> >> Fixes: 979f2bae0 ("doc: improve multiport PF in nfp guide") >> Cc: stable@dpdk.org >> >> Signed-off-by: Chaoyong.He >> Signed-off-by: Heinrich Kuhn >> --- >>   doc/guides/nics/nfp.rst | 14 +++++++++----- >>   1 file changed, 9 insertions(+), 5 deletions(-) >> >> diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst >> index fef99973b..2b170539d 100644 >> --- a/doc/guides/nics/nfp.rst >> +++ b/doc/guides/nics/nfp.rst >> @@ -117,15 +117,19 @@ although once they are created, DPDK apps should be able >> to use them as normal >>   PCI ports. >>   NFP ports belonging to same PF can be seen inside PMD initialization with a >> -suffix added to the PCI ID: wwww:xx:yy.z_port_n. For example, a PF with PCI ID >> +suffix added to the PCI ID: wwww:xx:yy.z_portn. For example, a PF with PCI ID >>   0000:03:00.0 and four ports is seen by the PMD code as: >>      .. code-block:: console >> -      0000:03:00.0_port_0 >> -      0000:03:00.0_port_1 >> -      0000:03:00.0_port_2 >> -      0000:03:00.0_port_3 >> +      0000:03:00.0_port0 >> +      0000:03:00.0_port1 >> +      0000:03:00.0_port2 >> +      0000:03:00.0_port3 >> + > > +1 to fix. > >> +Some dpdk applications can choose to use the MAC address to identify ports, >> +OVS-DPDK is one such example, please refer to: >> +https://docs.openvswitch.org/en/latest/howto/dpdk/ > > This is not PMD specific information, not sure to have here, > also not sure to have an external link here, basically for the maintenance > concerns, should we document this usage withing DPDK in a wider than a PMD scope? > Ping. Will there be a new version? If not I can just get the fix part (s/port_n/portn).