DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: john.mcnamara@intel.com, marko.kovacevic@intel.com
Cc: anatoly.burakov@intel.com, dev@dpdk.org,
	Bruce Richardson <bruce.richardson@intel.com>
Subject: [dpdk-dev] [PATCH 4/5] doc: update section on loading FreeBSD kernel modules
Date: Fri,  3 Jan 2020 15:32:55 +0000	[thread overview]
Message-ID: <20200103153256.2895527-5-bruce.richardson@intel.com> (raw)
In-Reply-To: <20200103153256.2895527-1-bruce.richardson@intel.com>

The kernel modules are now installed in the correct system location on
install when using meson and ninja, so update the documentation to remove
any references to the "kmod" directory. Also, make a few additional updates
to improve clarity.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 65 ++++++++++++---------------
 1 file changed, 29 insertions(+), 36 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst
index c5d5379f6..e31c966b9 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -73,26 +73,25 @@ To run a DPDK application, physically contiguous memory is required.
 In the absence of non-transparent superpages, the included sources for the
 contigmem kernel module provides the ability to present contiguous blocks of
 memory for the DPDK to use. The contigmem module must be loaded into the
-running kernel before any DPDK is run.  The module is found in the kmod
-sub-directory of the DPDK target directory.
+running kernel before any DPDK is run. Once DPDK is installed on the
+system, the module can be found in the `/boot/modules` directory.
 
 The amount of physically contiguous memory along with the number of physically
 contiguous blocks to be reserved by the module can be set at runtime prior to
-module loading using:
-
-.. code-block:: console
+module loading using::
 
     kenv hw.contigmem.num_buffers=n
     kenv hw.contigmem.buffer_size=m
 
 The kernel environment variables can also be specified during boot by placing the
-following in ``/boot/loader.conf``::
+following in ``/boot/loader.conf``:
 
-    hw.contigmem.num_buffers=n hw.contigmem.buffer_size=m
+.. code-block:: shell
 
-The variables can be inspected using the following command:
+    hw.contigmem.num_buffers=n
+    hw.contigmem.buffer_size=m
 
-.. code-block:: console
+The variables can be inspected using the following command::
 
     sysctl -a hw.contigmem
 
@@ -100,18 +99,19 @@ Where n is the number of blocks and m is the size in bytes of each area of
 contiguous memory.  A default of two buffers of size 1073741824 bytes (1 Gigabyte)
 each is set during module load if they are not specified in the environment.
 
-The module can then be loaded using kldload (assuming that the current directory
-is the DPDK target directory):
-
-.. code-block:: console
+The module can then be loaded using kldload::
 
-    kldload ./kmod/contigmem.ko
+    kldload contigmem
 
 It is advisable to include the loading of the contigmem module during the boot
 process to avoid issues with potential memory fragmentation during later system
-up time.  This can be achieved by copying the module to the ``/boot/kernel/``
-directory and placing the following into ``/boot/loader.conf``::
+up time.  This can be achieved by placing lines similar to the following into
+``/boot/loader.conf``:
+
+.. code-block:: shell
 
+    hw.contigmem.num_buffers=1
+    hw.contigmem.buffer_size=1073741824
     contigmem_load="YES"
 
 .. note::
@@ -120,17 +120,13 @@ directory and placing the following into ``/boot/loader.conf``::
     ``hw.contigmem.num_buffers`` and ``hw.contigmem.buffer_size`` if the default values
     are not to be used.
 
-An error such as:
-
-.. code-block:: console
+An error such as::
 
     kldload: can't load ./x86_64-native-freebsd-gcc/kmod/contigmem.ko:
              Exec format error
 
 is generally attributed to not having enough contiguous memory
-available and can be verified via dmesg or ``/var/log/messages``:
-
-.. code-block:: console
+available and can be verified via dmesg or ``/var/log/messages``::
 
     kernel: contigmalloc failed for buffer <n>
 
@@ -142,13 +138,9 @@ Loading the DPDK nic_uio Module
 -------------------------------
 
 After loading the contigmem module, the ``nic_uio`` module must also be loaded into the
-running kernel prior to running any DPDK application.  This module must
-be loaded using the kldload command as shown below (assuming that the current
-directory is the DPDK target directory).
+running kernel prior to running any DPDK application, e.g. using::
 
-.. code-block:: console
-
-    kldload ./kmod/nic_uio.ko
+    kldload nic_uio
 
 .. note::
 
@@ -159,8 +151,9 @@ directory is the DPDK target directory).
 Currently loaded modules can be seen by using the ``kldstat`` command and a module
 can be removed from the running kernel by using ``kldunload <module_name>``.
 
-To load the module during boot, copy the ``nic_uio`` module to ``/boot/kernel``
-and place the following into ``/boot/loader.conf``::
+To load the module during boot place the following into ``/boot/loader.conf``:
+
+.. code-block:: shell
 
     nic_uio_load="YES"
 
@@ -184,7 +177,7 @@ Binding Network Ports to the nic_uio Module
 Device ownership can be viewed using the pciconf -l command. The example below shows
 four Intel® 82599 network ports under ``if_ixgbe`` module ownership.
 
-.. code-block:: console
+.. code-block:: none
 
     pciconf -l
     ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00
@@ -210,7 +203,7 @@ To avoid building a custom kernel, the ``nic_uio`` module can detach a network p
 from its current device driver. This is achieved by setting the ``hw.nic_uio.bdfs``
 kernel environment variable prior to loading ``nic_uio``, as follows::
 
-    hw.nic_uio.bdfs="b:d:f,b:d:f,..."
+    kenv hw.nic_uio.bdfs="b:d:f,b:d:f,..."
 
 Where a comma separated list of selectors is set, the list must not contain any
 whitespace.
@@ -222,7 +215,9 @@ upon loading, use the following command::
 
 The variable can also be specified during boot by placing the following into
 ``/boot/loader.conf``, before the previously-described ``nic_uio_load`` line - as
-shown::
+shown:
+
+.. code-block:: shell
 
     hw.nic_uio.bdfs="2:0:0,2:0:1"
     nic_uio_load="YES"
@@ -241,9 +236,7 @@ value, and reload the two drivers - first the original kernel driver, and then
 the ``nic_uio driver``. Note: the latter does not need to be reloaded unless there are
 ports that are still to be bound to it.
 
-Example commands to perform these steps are shown below:
-
-.. code-block:: console
+Example commands to perform these steps are shown below::
 
     kldunload nic_uio
     kldunload <original_driver>
-- 
2.24.1


  parent reply	other threads:[~2020-01-03 15:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-03 15:32 [dpdk-dev] [PATCH 0/5] Update docs for installing on FreeBSD Bruce Richardson
2020-01-03 15:32 ` [dpdk-dev] [PATCH 1/5] doc: update intro to FreeBSD GSG Bruce Richardson
2020-01-03 15:32 ` [dpdk-dev] [PATCH 2/5] doc: document installing from FreeBSD package Bruce Richardson
2020-01-03 15:32 ` [dpdk-dev] [PATCH 3/5] doc: add meson install instructions for FreeBSD Bruce Richardson
2020-01-03 15:32 ` Bruce Richardson [this message]
2020-01-03 15:32 ` [dpdk-dev] [PATCH 5/5] doc: update documentation on build and running FreeBSD apps Bruce Richardson
2020-02-16 10:04 ` [dpdk-dev] [PATCH 0/5] Update docs for installing on FreeBSD Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200103153256.2895527-5-bruce.richardson@intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).