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 D4735A0548; Mon, 26 Apr 2021 11:46:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC0DA41110; Mon, 26 Apr 2021 11:46:53 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 1225040140 for ; Mon, 26 Apr 2021 11:46:51 +0200 (CEST) IronPort-SDR: vCmgsvvx3l7dSmMFBxyakHUEkBgIXtvsqvS/CvNPvXaDWJSiM8mK3LjcXDZFR1v2h5PfsE7YYh geYgQ5nKcQcQ== X-IronPort-AV: E=McAfee;i="6200,9189,9965"; a="195861488" X-IronPort-AV: E=Sophos;i="5.82,252,1613462400"; d="scan'208";a="195861488" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 02:46:48 -0700 IronPort-SDR: Aml/Tg0g4IS5SkpVrHFEdy94ZkPGGVVLo9gEOe2+2M3/5d3RBksblcTctolwYy2YwIGNe0ROZQ v05uBsSno7Sw== X-IronPort-AV: E=Sophos;i="5.82,252,1613462400"; d="scan'208";a="429335119" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.240.23]) ([10.213.240.23]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 02:46:47 -0700 From: Ferruh Yigit References: <20210225114622.2431-1-heinrich.kuhn@netronome.com> <54de2177-d56c-2281-2e92-8603450a99c6@intel.com> Cc: dev@dpdk.org To: Heinrich Kuhn X-User: ferruhy Message-ID: <92790507-cabd-ba37-2016-9b5c48c2416f@intel.com> Date: Mon, 26 Apr 2021 10:46:43 +0100 MIME-Version: 1.0 In-Reply-To: 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 4/23/2021 5:18 PM, Ferruh Yigit wrote: > 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). Partially, for the fix part, Applied to dpdk-next-net/main, thanks.