X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fkernel_nic_interface.rst;h=1ce03ec1a374671fcfce5e1ce8a113d559053931;hb=dd22740cc291568f354279f5c38eef4a1d1dd3a0;hp=daf87f4a8edfcc697aefcbca159b32189a682cfa;hpb=d629b7b5fe812f0040b83d27d2ada33b003aa918;p=dpdk.git diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst index daf87f4a8e..1ce03ec1a3 100644 --- a/doc/guides/prog_guide/kernel_nic_interface.rst +++ b/doc/guides/prog_guide/kernel_nic_interface.rst @@ -65,7 +65,7 @@ disabled, and the default carrier state of KNI interfaces is set to *off*. .. code-block:: console - # insmod kmod/rte_kni.ko + # insmod /kernel/linux/kni/rte_kni.ko .. _kni_loopback_mode: @@ -77,14 +77,14 @@ by specifying the ``lo_mode`` parameter: .. code-block:: console - # insmod kmod/rte_kni.ko lo_mode=lo_mode_fifo + # insmod /kernel/linux/kni/rte_kni.ko lo_mode=lo_mode_fifo The ``lo_mode_fifo`` loopback option will loop back ring enqueue/dequeue operations in kernel space. .. code-block:: console - # insmod kmod/rte_kni.ko lo_mode=lo_mode_fifo_skb + # insmod /kernel/linux/kni/rte_kni.ko lo_mode=lo_mode_fifo_skb The ``lo_mode_fifo_skb`` loopback option will loop back ring enqueue/dequeue operations and sk buffer copies in kernel space. @@ -105,7 +105,7 @@ Single kernel thread mode is enabled as follows: .. code-block:: console - # insmod kmod/rte_kni.ko kthread_mode=single + # insmod /kernel/linux/kni/rte_kni.ko kthread_mode=single This mode will create only one kernel thread for all KNI interfaces to receive data on the kernel side. By default, this kernel thread is not @@ -122,7 +122,7 @@ kernel thread mode is enabled as follows: .. code-block:: console - # insmod kmod/rte_kni.ko kthread_mode=multiple + # insmod /kernel/linux/kni/rte_kni.ko kthread_mode=multiple This mode will create a separate kernel thread for each KNI interface to receive data on the kernel side. The core affinity of each ``kni_thread`` @@ -163,13 +163,13 @@ To set the default carrier state to *on*: .. code-block:: console - # insmod kmod/rte_kni.ko carrier=on + # insmod /kernel/linux/kni/rte_kni.ko carrier=on To set the default carrier state to *off*: .. code-block:: console - # insmod kmod/rte_kni.ko carrier=off + # insmod /kernel/linux/kni/rte_kni.ko carrier=off If the ``carrier`` parameter is not specified, the default carrier state of KNI interfaces will be set to *off*. @@ -178,7 +178,7 @@ KNI Creation and Deletion ------------------------- Before any KNI interfaces can be created, the ``rte_kni`` kernel module must -be loaded into the kernel and configured withe ``rte_kni_init()`` function. +be loaded into the kernel and configured with the ``rte_kni_init()`` function. The KNI interfaces are created by a DPDK application dynamically via the ``rte_kni_alloc()`` function. @@ -235,6 +235,15 @@ application functions: will be called which calls ``rte_eth_promiscuous_()`` on the specified ``port_id``. +``config_allmulticast``: + + Called when the user changes the allmulticast state of the KNI interface. + For example, when the user runs ``ifconfig [-]allmulti``. If the + user sets this callback function to NULL, but sets the ``port_id`` field to + a value other than -1, a default callback handler in the rte_kni library + ``kni_config_allmulticast()`` will be called which calls + ``rte_eth_allmulticast_()`` on the specified ``port_id``. + In order to run these callbacks, the application must periodically call the ``rte_kni_handle_request()`` function. Any user callback function registered will be called directly from ``rte_kni_handle_request()`` so @@ -245,7 +254,7 @@ to create a separate thread or secondary process to periodically call The KNI interfaces can be deleted by a DPDK application with ``rte_kni_release()``. All KNI interfaces not explicitly deleted will be -deleted when the the ``/dev/kni`` device is closed, either explicitly with +deleted when the ``/dev/kni`` device is closed, either explicitly with ``rte_kni_close()`` or when the DPDK application is closed. DPDK mbuf Flow @@ -268,12 +277,16 @@ Use Case: Ingress ----------------- On the DPDK RX side, the mbuf is allocated by the PMD in the RX thread context. -This thread will enqueue the mbuf in the rx_q FIFO. +This thread will enqueue the mbuf in the rx_q FIFO, +and the next pointers in mbuf-chain will convert to physical address. The KNI thread will poll all KNI active devices for the rx_q. If an mbuf is dequeued, it will be converted to a sk_buff and sent to the net stack via netif_rx(). -The dequeued mbuf must be freed, so the same pointer is sent back in the free_q FIFO. +The dequeued mbuf must be freed, so the same pointer is sent back in the free_q FIFO, +and next pointers must convert back to virtual address if exists before put in the free_q FIFO. The RX thread, in the same main loop, polls this FIFO and frees the mbuf after dequeuing it. +The address conversion of the next pointer is to prevent the chained mbuf +in different hugepage segments from causing kernel crash. Use Case: Egress ---------------- @@ -287,10 +300,24 @@ The sk_buff is then freed and the mbuf sent in the tx_q FIFO. The DPDK TX thread dequeues the mbuf and sends it to the PMD via ``rte_eth_tx_burst()``. It then puts the mbuf back in the cache. +IOVA = VA: Support +------------------ + +KNI operates in IOVA_VA scheme when + +- LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0) and +- EAL option `iova-mode=va` is passed or bus IOVA scheme in the DPDK is selected + as RTE_IOVA_VA. + +Due to IOVA to KVA address translations, based on the KNI use case there +can be a performance impact. For mitigation, forcing IOVA to PA via EAL +"--iova-mode=pa" option can be used, IOVA_DC bus iommu scheme can also +result in IOVA as PA. + Ethtool ------- -Ethtool is a Linux-specific tool with corresponding support in the kernel -where each net device must register its own callbacks for the supported operations. -The current implementation uses the igb/ixgbe modified Linux drivers for ethtool support. -Ethtool is not supported in i40e and VMs (VF or EM devices). +Ethtool is a Linux-specific tool with corresponding support in the kernel. +The current version of kni provides minimal ethtool functionality +including querying version and link state. It does not support link +control, statistics, or dumping device registers.