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 C1E71A0548; Mon, 26 Apr 2021 11:48:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A86BC4119B; Mon, 26 Apr 2021 11:48:48 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 80D6B40140; Mon, 26 Apr 2021 11:48:47 +0200 (CEST) IronPort-SDR: gjY8O9NfW46FKZQwUXgU8DYz5BPPdjZXzdiP6tt7/Xu5zfnnWlMNL4nXxmYbC3kNYrbWdtWomF xJo+qdNUNJCw== X-IronPort-AV: E=McAfee;i="6200,9189,9965"; a="217005544" X-IronPort-AV: E=Sophos;i="5.82,252,1613462400"; d="scan'208";a="217005544" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 02:48:42 -0700 IronPort-SDR: HiMMLBva7Lgp1/ocZAkoPh36Fgtdt+ZFFTv8LJ28es2P2GUcB3z3eN/ONkuqQhmHsm0WFKJfkS 6ZBJzlnrZVbQ== X-IronPort-AV: E=Sophos;i="5.82,252,1613462400"; d="scan'208";a="429335582" 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:48:40 -0700 From: Ferruh Yigit To: Thomas Monjalon , David Marchand , Akhil Goyal , "jerinj@marvell.com" , Maxime Coquelin , Qi Zhang , Raslan Darawsheh , Ajit Khaparde Cc: dev@dpdk.org, Heinrich Kuhn , "techboard@dpdk.org" References: <20210225114622.2431-1-heinrich.kuhn@netronome.com> <54de2177-d56c-2281-2e92-8603450a99c6@intel.com> <92790507-cabd-ba37-2016-9b5c48c2416f@intel.com> X-User: ferruhy Message-ID: Date: Mon, 26 Apr 2021 10:48:38 +0100 MIME-Version: 1.0 In-Reply-To: <92790507-cabd-ba37-2016-9b5c48c2416f@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 4/26/2021 10:46 AM, Ferruh Yigit wrote: > 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. Hi Thomas, David, Akhil, Jerin, Maxime, Qi, Raslan, Ajit, For the doc patches, the subsystem prefix 'doc:' is too wide, what do you think to extend it to include the component, like for this patch: "doc/nics/nfp: fix multiport syntax"