X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fkernel_nic_interface.rst;h=de5d75bd4ca17bc74c76d0b607c0315977f43d80;hb=cbcda56cced98ec6cc214ed89df0703ddeb7723e;hp=7fcbd936f9a11a278f22ffe489581821fc34ca5e;hpb=ff1e35fb5f8330f89d13f58c9fb767b5bd188940;p=dpdk.git diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst index 7fcbd936f9..de5d75bd4c 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*. @@ -227,7 +227,7 @@ application functions: ``config_promiscusity``: - Called when the user changes the promiscusity state of the KNI + Called when the user changes the promiscuity state of the KNI interface. For example, when the user runs ``ip link set promisc [on|off] dev ``. If the user sets this callback function to NULL, but sets the ``port_id`` field to a value other than -1, a default @@ -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.