From patchwork Mon Nov 28 22:13:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chautru, Nicolas" X-Patchwork-Id: 120211 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 48802A0093; Mon, 28 Nov 2022 23:14:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7454542D18; Mon, 28 Nov 2022 23:14:08 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id E047D4067E for ; Mon, 28 Nov 2022 23:14:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669673645; x=1701209645; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=A9sXkXL6iZXg3w3C5KOJ6KvTs6CPqrpkdFUefZh5wiU=; b=ROYVtANS2gihisoKJnYFZ8nz509v/qcT5OEyGq02xcJV31zATfVm+u1E o63CKHrbH+x0zVqbz5MbVIxCRGnW0rLlaT3eRKWylDqsVVjbDuRGYn4az aOBLPXYhEcW1xGucjzigI7X2b4dSoSjaxLMKFIjFBtoxj4jOHHvUW94El wSvPk7yCrzBHkunxDYmIzjJ2aSCUn75aK+QJVb7z48U9S7eYOKEANVg2D 95QVwB601mE3f/MuskTS7IocqD08D+FmfCW3CbELgIWdbaVMSfeJQ9KJ9 FpsMfRBRAW/7Z2AUh77J4nS+ikTjnB1CHsTfXtneqfe5Woqk+s6RoluwV Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="295338072" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="295338072" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 14:14:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="817987259" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="817987259" Received: from unknown (HELO icx-npg-scs1-cp1.localdomain) ([10.233.180.245]) by orsmga005.jf.intel.com with ESMTP; 28 Nov 2022 14:14:02 -0800 From: Nicolas Chautru To: dev@dpdk.org, thomas@monjalon.net, gakhil@marvell.com, maxime.coquelin@redhat.com Cc: hernan.vargas@intel.com, Nicolas Chautru Subject: [PATCH v1 2/3] doc: simplify the binding steps Date: Mon, 28 Nov 2022 14:13:38 -0800 Message-Id: <20221128221339.15654-3-nicolas.chautru@intel.com> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20221128221339.15654-1-nicolas.chautru@intel.com> References: <20221128221339.15654-1-nicolas.chautru@intel.com> MIME-Version: 1.0 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 The steps for binding to kernel modules which are generic are now only implicit and pointing towards common documentation. Signed-off-by: Nicolas Chautru --- doc/guides/bbdevs/acc100.rst | 78 ++++------------------------- doc/guides/bbdevs/acc200.rst | 74 ++++----------------------- doc/guides/bbdevs/fpga_5gnr_fec.rst | 77 ++++------------------------ doc/guides/bbdevs/fpga_lte_fec.rst | 77 ++++------------------------ 4 files changed, 36 insertions(+), 270 deletions(-) diff --git a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst index 8a275dcdd4..60fccd3bc8 100644 --- a/doc/guides/bbdevs/acc100.rst +++ b/doc/guides/bbdevs/acc100.rst @@ -101,77 +101,15 @@ commands for ACC100 and ACC101 respectively: sudo lspci -vd8086:0d5c sudo lspci -vd8086:57c4 -The physical and virtual functions are compatible with Linux UIO drivers: -``vfio`` and ``igb_uio``. However, in order to work the 5G/4G -FEC device first needs to be bound to one of these linux drivers through DPDK. +Binding and Virtual Functions enablement +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bind PF UIO driver(s) -~~~~~~~~~~~~~~~~~~~~~ - -Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use -``lspci`` to confirm the PF device is under use by ``igb_uio`` DPDK UIO driver. - -The igb_uio driver may be bound to the PF PCI device using one of two methods for ACC100 -(for ACC101 the device id ``57c4`` should be used in lieu of ``0d5c``): - - -1. PCI functions (physical or virtual, depending on the use case) can be bound to -the UIO driver by repeating this command for every function. - -.. code-block:: console - - cd - insmod ./build/kmod/igb_uio.ko - echo "8086 0d5c" > /sys/bus/pci/drivers/igb_uio/new_id - lspci -vd8086:0d5c - - -2. Another way to bind PF with DPDK UIO driver is by using the ``dpdk-devbind.py`` tool - -.. code-block:: console - - cd - ./usertools/dpdk-devbind.py -b igb_uio 0000:06:00.0 - -where the PCI device ID (example: 0000:06:00.0) is obtained using lspci -vd8086:0d5c - - -In a similar way the 5G/4G FEC PF may be bound with vfio-pci as any PCIe device. - - -Enable Virtual Functions -~~~~~~~~~~~~~~~~~~~~~~~~ - -Now, it should be visible in the printouts that PCI PF is under igb_uio control -"``Kernel driver in use: igb_uio``" - -To show the number of available VFs on the device, read ``sriov_totalvfs`` file.. - -.. code-block:: console - - cat /sys/bus/pci/devices/0000\:\:./sriov_totalvfs - - where 0000\:\:. is the PCI device ID - - -To enable VFs via igb_uio, echo the number of virtual functions intended to -enable to ``max_vfs`` file.. - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./max_vfs - - -Afterwards, all VFs must be bound to appropriate UIO drivers as required, same -way it was done with the physical function previously. - -Enabling SR-IOV via vfio driver is pretty much the same, except that the file -name is different: - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./sriov_numvfs +The PMD relies on kernel modules to interface with the device: both UIO and VFIO kernel modules +are supported. +See :ref:`linux_gsg_binding_kernel` section for more details, notably with regards to +generic kernel modules binding and VF enablement. +More details on usage model is captured in the :ref:`pf_bb_config_acc100` section. Configure the VFs through PF @@ -232,6 +170,8 @@ of these tests will depend on the device 5G/4G FEC capabilities which may cause testcases to be skipped, but no failure should be reported. +.. _pf_bb_config_acc100: + Alternate Baseband Device configuration tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/bbdevs/acc200.rst b/doc/guides/bbdevs/acc200.rst index 012b3870a8..410f18d9bc 100644 --- a/doc/guides/bbdevs/acc200.rst +++ b/doc/guides/bbdevs/acc200.rst @@ -110,73 +110,15 @@ can be listed through these commands for ACC200: sudo lspci -vd8086:57c0 -The physical and virtual functions are compatible with Linux UIO drivers: -``vfio`` and ``igb_uio``. -However, in order to work the 5G/4G FEC device first needs to be bound -to one of these Linux drivers through DPDK. +Binding and Virtual Functions enablement +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bind PF UIO driver(s) -~~~~~~~~~~~~~~~~~~~~~ - -Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use -``lspci`` to confirm the PF device is under use by ``igb_uio`` DPDK UIO driver. - -The igb_uio driver may be bound to the PF PCI device using one of two methods -for ACC200: - -#. PCI functions (physical or virtual, depending on the use case) can be bound -to the UIO driver by repeating this command for every function. - -.. code-block:: console - - cd - insmod build/kmod/igb_uio.ko - echo "8086 57c0" > /sys/bus/pci/drivers/igb_uio/new_id - lspci -vd8086:57c0 - -#. Another way to bind PF with DPDK UIO driver is by using the ``dpdk-devbind.py`` tool - -.. code-block:: console - - cd - usertools/dpdk-devbind.py -b igb_uio 0000:f7:00.0 - -where the PCI device ID (example: 0000:f7:00.0) is obtained using ``lspci -vd8086:57c0``. - -In a similar way the PF may be bound with vfio-pci as any PCIe device. - - -Enable Virtual Functions -~~~~~~~~~~~~~~~~~~~~~~~~ - -Now, it should be visible in the printouts that PCI PF is under igb_uio control -"``Kernel driver in use: igb_uio``" - -To show the number of available VFs on the device, read ``sriov_totalvfs`` file. - -.. code-block:: console - - cat /sys/bus/pci/devices/0000\:\:./sriov_totalvfs - -where ``0000\:\:.`` is the PCI device ID - -To enable VFs via igb_uio, echo the number of virtual functions intended -to enable to ``max_vfs`` file. - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./max_vfs - -Afterwards, all VFs must be bound to appropriate UIO drivers as required, -same way it was done with the physical function previously. - -Enabling SR-IOV via VFIO driver is pretty much the same, -except that the file name is different: - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./sriov_numvfs +The PMD relies on kernel modules to interface with the device: both UIO and VFIO kernel modules +are supported. +See :ref:`linux_gsg_binding_kernel` section for more details, notably with regards to +generic kernel modules binding and VF enablement. +More details on usage model is captured in the :ref:`pf_bb_config_acc200` section. Configure the VFs through PF @@ -241,6 +183,8 @@ The results of these tests will depend on the device capabilities which may cause some test cases to be skipped, but no failure should be reported. +.. _pf_bb_config_acc200: + Alternate Baseband Device configuration tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst index 9d71585e9e..b2afd1bb2a 100644 --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst @@ -71,76 +71,15 @@ When the device first powers up, its PCI Physical Functions (PF) can be listed t sudo lspci -vd8086:0d8f -The physical and virtual functions are compatible with Linux UIO drivers: -``vfio`` and ``igb_uio``. However, in order to work the FPGA 5GNR FEC device firstly needs -to be bound to one of these linux drivers through DPDK. +Binding and Virtual Functions enablement +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bind PF UIO driver(s) -~~~~~~~~~~~~~~~~~~~~~ - -Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use -``lspci`` to confirm the PF device is under use by ``igb_uio`` DPDK UIO driver. - -The igb_uio driver may be bound to the PF PCI device using one of two methods: - - -1. PCI functions (physical or virtual, depending on the use case) can be bound to -the UIO driver by repeating this command for every function. - -.. code-block:: console - - insmod igb_uio.ko - echo "8086 0d8f" > /sys/bus/pci/drivers/igb_uio/new_id - lspci -vd8086:0d8f - - -2. Another way to bind PF with DPDK UIO driver is by using the ``dpdk-devbind.py`` tool - -.. code-block:: console - - cd - ./usertools/dpdk-devbind.py -b igb_uio 0000:06:00.0 - -where the PCI device ID (example: 0000:06:00.0) is obtained using lspci -vd8086:0d8f - - -In the same way the FPGA 5GNR FEC PF can be bound with vfio, but vfio driver does not -support SR-IOV configuration right out of the box, so it will need to be patched. - - -Enable Virtual Functions -~~~~~~~~~~~~~~~~~~~~~~~~ - -Now, it should be visible in the printouts that PCI PF is under igb_uio control -"``Kernel driver in use: igb_uio``" - -To show the number of available VFs on the device, read ``sriov_totalvfs`` file.. - -.. code-block:: console - - cat /sys/bus/pci/devices/0000\:\:./sriov_totalvfs - - where 0000\:\:. is the PCI device ID - - -To enable VFs via igb_uio, echo the number of virtual functions intended to -enable to ``max_vfs`` file.. - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./max_vfs - - -Afterwards, all VFs must be bound to appropriate UIO drivers as required, same -way it was done with the physical function previously. - -Enabling SR-IOV via vfio driver is pretty much the same, except that the file -name is different: - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./sriov_numvfs +The PMD relies on kernel modules to interface with the device: both UIO and VFIO kernel modules +are supported. +See :ref:`linux_gsg_binding_kernel` section for more details, notably with regards to +generic kernel modules binding and VF enablement. +More details on usage model is captured in the :ref:`pf_bb_config_fpga_5gnr` section. Configure the VFs through PF @@ -274,6 +213,8 @@ a range of additional tests under the test_vectors folder, which may be useful. of these tests will depend on the FPGA 5GNR FEC capabilities. +.. _pf_bb_config_fpga_5gnr: + Alternate Baseband Device configuration tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst b/doc/guides/bbdevs/fpga_lte_fec.rst index c3379c24e3..77d4b418ca 100644 --- a/doc/guides/bbdevs/fpga_lte_fec.rst +++ b/doc/guides/bbdevs/fpga_lte_fec.rst @@ -70,76 +70,15 @@ When the device first powers up, its PCI Physical Functions (PF) can be listed t sudo lspci -vd1172:5052 -The physical and virtual functions are compatible with Linux UIO drivers: -``vfio`` and ``igb_uio``. However, in order to work the FPGA LTE FEC device firstly needs -to be bound to one of these linux drivers through DPDK. +Binding and Virtual Functions enablement +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bind PF UIO driver(s) -~~~~~~~~~~~~~~~~~~~~~ - -Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use -``lspci`` to confirm the PF device is under use by ``igb_uio`` DPDK UIO driver. - -The igb_uio driver may be bound to the PF PCI device using one of two methods: - - -1. PCI functions (physical or virtual, depending on the use case) can be bound to -the UIO driver by repeating this command for every function. - -.. code-block:: console - - insmod igb_uio.ko - echo "1172 5052" > /sys/bus/pci/drivers/igb_uio/new_id - lspci -vd1172: - - -2. Another way to bind PF with DPDK UIO driver is by using the ``dpdk-devbind.py`` tool - -.. code-block:: console - - cd - ./usertools/dpdk-devbind.py -b igb_uio 0000:06:00.0 - -where the PCI device ID (example: 0000:06:00.0) is obtained using lspci -vd1172: - - -In the same way the FPGA LTE FEC PF can be bound with vfio, but vfio driver does not -support SR-IOV configuration right out of the box, so it will need to be patched. - - -Enable Virtual Functions -~~~~~~~~~~~~~~~~~~~~~~~~ - -Now, it should be visible in the printouts that PCI PF is under igb_uio control -"``Kernel driver in use: igb_uio``" - -To show the number of available VFs on the device, read ``sriov_totalvfs`` file.. - -.. code-block:: console - - cat /sys/bus/pci/devices/0000\:\:./sriov_totalvfs - - where 0000\:\:. is the PCI device ID - - -To enable VFs via igb_uio, echo the number of virtual functions intended to -enable to ``max_vfs`` file.. - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./max_vfs - - -Afterwards, all VFs must be bound to appropriate UIO drivers as required, same -way it was done with the physical function previously. - -Enabling SR-IOV via vfio driver is pretty much the same, except that the file -name is different: - -.. code-block:: console - - echo > /sys/bus/pci/devices/0000\:\:./sriov_numvfs +The PMD relies on kernel modules to interface with the device: both UIO and VFIO kernel modules +are supported. +See :ref:`linux_gsg_binding_kernel` section for more details, notably with regards to +generic kernel modules binding and VF enablement. +More details on usage model is captured in the :ref:`_pf_bb_config_fpga_lte` section. Configure the VFs through PF @@ -293,6 +232,8 @@ of these tests will depend on the FPGA LTE FEC capabilities: - ``turbo_enc_c4_k4800_r2_e14412_crc24b.data`` +.. _pf_bb_config_fpga_lte: + Alternate Baseband Device configuration tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~