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 759D2A055D for ; Mon, 1 Mar 2021 14:45:51 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 65DED22A2A3; Mon, 1 Mar 2021 14:45:51 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id CC75940041; Mon, 1 Mar 2021 14:45:47 +0100 (CET) IronPort-SDR: dkP3igDayKxyhzc4kqWNZR3kV/ZMgyflxUiPz6ajCpmqnSkR5uuP5x5XdB+3iCWsBAl0NR0QpK iZSU2mYdheag== X-IronPort-AV: E=McAfee;i="6000,8403,9909"; a="250515733" X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="250515733" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 05:45:46 -0800 IronPort-SDR: 7QS634moEuZqpjXYjehUYm9tDXk6EKYTXv2hQk9p6GfHvPLJYukN2c6+oQNZuuvVjNN/0W77Ov nNhMWNizFlpg== X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="397727194" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.216.186]) ([10.213.216.186]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 05:45:45 -0800 To: Heinrich Kuhn , dev@dpdk.org Cc: "Chaoyong.He" , stable@dpdk.org References: <20210225114622.2431-1-heinrich.kuhn@netronome.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <54de2177-d56c-2281-2e92-8603450a99c6@intel.com> Date: Mon, 1 Mar 2021 13:45:41 +0000 MIME-Version: 1.0 In-Reply-To: <20210225114622.2431-1-heinrich.kuhn@netronome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] doc: fix nfp multiport syntax X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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?