From patchwork Mon Nov 28 23:19:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chautru, Nicolas" X-Patchwork-Id: 120214 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 648FDA0093; Tue, 29 Nov 2022 00:20:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6CBD242D11; Tue, 29 Nov 2022 00:20:09 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 1BB8E4021E for ; Tue, 29 Nov 2022 00:20:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669677606; x=1701213606; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hvEqtgYRv0XtqtECU4HMGY1c8FLWXyDuEoYE9lGZpQU=; b=JA++QMNzA3cO9bhGy13bQ5MPX+BXBRjw23Qkkqo35+P6qEJwzr68WBjF /Q/z1i3/QQA6VMpPdDfzZ+9+KFIMXhNWhslv/0yLX8XsNc/w7unT/NI0/ nZ+dGH4RETEcDkPhEkbI0lSP1Ze8f8DitXs3bMv0+fJBR1SFAFsPw4vOY xAFSsFyITaoxFNDzwhDNhhQZ8XpdSjptmCkUprleX8zlq0/OWA1MNWQm+ IUsHcoekuvGr7IqMGdb8sF0E0JKTQBtPtXo4reDEa0PsP+IWMVS4aIEIA HUvYt0nVc5085tiZQZwbkAD16ihMRfhk1T0yvRizqsE+0EJqiARgU6vyj w==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="379231960" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="379231960" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 15:20:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="594049131" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="594049131" Received: from unknown (HELO icx-npg-scs1-cp1.localdomain) ([10.233.180.245]) by orsmga003.jf.intel.com with ESMTP; 28 Nov 2022 15:20:03 -0800 From: Nicolas Chautru To: dev@dpdk.org, thomas@monjalon.net Cc: maxime.coquelin@redhat.com, hernan.vargas@intel.com, Nicolas Chautru Subject: [PATCH v4 2/3] doc: simplify the binding steps Date: Mon, 28 Nov 2022 15:19:39 -0800 Message-Id: <20221128231940.15961-3-nicolas.chautru@intel.com> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20221128231940.15961-1-nicolas.chautru@intel.com> References: <20221128231940.15961-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..5e867c6bbd 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~