1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright (c) 2017, Cisco Systems, Inc. 3 All rights reserved. 4 5ENIC Poll Mode Driver 6===================== 7 8ENIC PMD is the DPDK poll-mode driver for the Cisco System Inc. VIC Ethernet 9NICs. These adapters are also referred to as vNICs below. If you are running 10or would like to run DPDK software applications on Cisco UCS servers using 11Cisco VIC adapters the following documentation is relevant. 12 13How to obtain ENIC PMD integrated DPDK 14-------------------------------------- 15 16ENIC PMD support is integrated into the DPDK suite. dpdk-<version>.tar.gz 17should be downloaded from https://core.dpdk.org/download/ 18 19 20Configuration information 21------------------------- 22 23- **vNIC Configuration Parameters** 24 25 - **Number of Queues** 26 27 The maximum number of receive queues (RQs), work queues (WQs) and 28 completion queues (CQs) are configurable on a per vNIC basis 29 through the Cisco UCS Manager (CIMC or UCSM). 30 31 These values should be configured as follows: 32 33 - The number of WQs should be greater or equal to the value of the 34 expected nb_tx_q parameter in the call to 35 rte_eth_dev_configure() 36 37 - The number of RQs configured in the vNIC should be greater or 38 equal to *twice* the value of the expected nb_rx_q parameter in 39 the call to rte_eth_dev_configure(). With the addition of Rx 40 scatter, a pair of RQs on the vnic is needed for each receive 41 queue used by DPDK, even if Rx scatter is not being used. 42 Having a vNIC with only 1 RQ is not a valid configuration, and 43 will fail with an error message. 44 45 - The number of CQs should set so that there is one CQ for each 46 WQ, and one CQ for each pair of RQs. 47 48 For example: If the application requires 3 Rx queues, and 3 Tx 49 queues, the vNIC should be configured to have at least 3 WQs, 6 50 RQs (3 pairs), and 6 CQs (3 for use by WQs + 3 for use by the 3 51 pairs of RQs). 52 53 - **Size of Queues** 54 55 Likewise, the number of receive and transmit descriptors are configurable on 56 a per-vNIC basis via the UCS Manager and should be greater than or equal to 57 the nb_rx_desc and nb_tx_desc parameters expected to be used in the calls 58 to rte_eth_rx_queue_setup() and rte_eth_tx_queue_setup() respectively. 59 An application requesting more than the set size will be limited to that 60 size. 61 62 Unless there is a lack of resources due to creating many vNICs, it 63 is recommended that the WQ and RQ sizes be set to the maximum. This 64 gives the application the greatest amount of flexibility in its 65 queue configuration. 66 67 - *Note*: Since the introduction of Rx scatter, for performance 68 reasons, this PMD uses two RQs on the vNIC per receive queue in 69 DPDK. One RQ holds descriptors for the start of a packet, and the 70 second RQ holds the descriptors for the rest of the fragments of 71 a packet. This means that the nb_rx_desc parameter to 72 rte_eth_rx_queue_setup() can be a greater than 4096. The exact 73 amount will depend on the size of the mbufs being used for 74 receives, and the MTU size. 75 76 For example: If the mbuf size is 2048, and the MTU is 9000, then 77 receiving a full size packet will take 5 descriptors, 1 from the 78 start-of-packet queue, and 4 from the second queue. Assuming 79 that the RQ size was set to the maximum of 4096, then the 80 application can specify up to 1024 + 4096 as the nb_rx_desc 81 parameter to rte_eth_rx_queue_setup(). 82 83 - **Interrupts** 84 85 At least one interrupt per vNIC interface should be configured in the UCS 86 manager regardless of the number receive/transmit queues. The ENIC PMD 87 uses this interrupt to get information about link status and errors 88 in the fast path. 89 90 In addition to the interrupt for link status and errors, when using Rx queue 91 interrupts, increase the number of configured interrupts so that there is at 92 least one interrupt for each Rx queue. For example, if the app uses 3 Rx 93 queues and wants to use per-queue interrupts, configure 4 (3 + 1) interrupts. 94 95 - **Receive Side Scaling** 96 97 In order to fully utilize RSS in DPDK, enable all RSS related settings in 98 CIMC or UCSM. These include the following items listed under 99 Receive Side Scaling: 100 TCP, IPv4, TCP-IPv4, IPv6, TCP-IPv6, IPv6 Extension, TCP-IPv6 Extension. 101 102 103SR-IOV mode utilization 104----------------------- 105 106UCS blade servers configured with dynamic vNIC connection policies in UCSM 107are capable of supporting SR-IOV. SR-IOV virtual functions (VFs) are 108specialized vNICs, distinct from regular Ethernet vNICs. These VFs can be 109directly assigned to virtual machines (VMs) as 'passthrough' devices. 110 111In UCS, SR-IOV VFs require the use of the Cisco Virtual Machine Fabric Extender 112(VM-FEX), which gives the VM a dedicated 113interface on the Fabric Interconnect (FI). Layer 2 switching is done at 114the FI. This may eliminate the requirement for software switching on the 115host to route intra-host VM traffic. 116 117Please refer to `Creating a Dynamic vNIC Connection Policy 118<http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/sw/vm_fex/vmware/gui/config_guide/b_GUI_VMware_VM-FEX_UCSM_Configuration_Guide/b_GUI_VMware_VM-FEX_UCSM_Configuration_Guide_chapter_010.html#task_433E01651F69464783A68E66DA8A47A5>`_ 119for information on configuring SR-IOV adapter policies and port profiles 120using UCSM. 121 122Once the policies are in place and the host OS is rebooted, VFs should be 123visible on the host, E.g.: 124 125.. code-block:: console 126 127 # lspci | grep Cisco | grep Ethernet 128 0d:00.0 Ethernet controller: Cisco Systems Inc VIC Ethernet NIC (rev a2) 129 0d:00.1 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 130 0d:00.2 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 131 0d:00.3 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 132 0d:00.4 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 133 0d:00.5 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 134 0d:00.6 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 135 0d:00.7 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 136 137Enable Intel IOMMU on the host and install KVM and libvirt, and reboot again as 138required. Then, using libvirt, create a VM instance with an assigned device. 139Below is an example ``interface`` block (part of the domain configuration XML) 140that adds the host VF 0d:00:01 to the VM. ``profileid='pp-vlan-25'`` indicates 141the port profile that has been configured in UCSM. 142 143.. code-block:: console 144 145 <interface type='hostdev' managed='yes'> 146 <mac address='52:54:00:ac:ff:b6'/> 147 <driver name='vfio'/> 148 <source> 149 <address type='pci' domain='0x0000' bus='0x0d' slot='0x00' function='0x1'/> 150 </source> 151 <virtualport type='802.1Qbh'> 152 <parameters profileid='pp-vlan-25'/> 153 </virtualport> 154 </interface> 155 156 157Alternatively, the configuration can be done in a separate file using the 158``network`` keyword. These methods are described in the libvirt documentation for 159`Network XML format <https://libvirt.org/formatnetwork.html>`_. 160 161When the VM instance is started, libvirt will bind the host VF to 162vfio, complete provisioning on the FI and bring up the link. 163 164.. note:: 165 166 It is not possible to use a VF directly from the host because it is not 167 fully provisioned until libvirt brings up the VM that it is assigned 168 to. 169 170In the VM instance, the VF will now be visible. E.g., here the VF 00:04.0 is 171seen on the VM instance and should be available for binding to a DPDK. 172 173.. code-block:: console 174 175 # lspci | grep Ether 176 00:04.0 Ethernet controller: Cisco Systems Inc VIC SR-IOV VF (rev a2) 177 178Follow the normal DPDK install procedure, binding the VF to either ``igb_uio`` 179or ``vfio`` in non-IOMMU mode. 180 181In the VM, the kernel enic driver may be automatically bound to the VF during 182boot. Unbinding it currently hangs due to a known issue with the driver. To 183work around the issue, block the enic module as follows. 184Please see :ref:`Limitations <enic_limitations>` for limitations in 185the use of SR-IOV. 186 187.. code-block:: console 188 189 # cat /etc/modprobe.d/enic.conf 190 blacklist enic 191 192 # dracut --force 193 194.. note:: 195 196 Passthrough does not require SR-IOV. If VM-FEX is not desired, the user 197 may create as many regular vNICs as necessary and assign them to VMs as 198 passthrough devices. Since these vNICs are not SR-IOV VFs, using them as 199 passthrough devices do not require libvirt, port profiles, and VM-FEX. 200 201 202.. _enic-generic-flow-api: 203 204Generic Flow API support 205------------------------ 206 207Generic Flow API (also called "rte_flow" API) is supported. More advanced 208capabilities are available when "Advanced Filtering" is enabled on the adapter. 209Advanced filtering was added to 1300 series VIC firmware starting with version 2102.0.13 for C-series UCS servers and version 3.1.2 for UCSM managed blade 211servers. Advanced filtering is available on 1400 series adapters and beyond. 212To enable advanced filtering, the 'Advanced filter' radio button should be 213selected via CIMC or UCSM followed by a reboot of the server. 214 215- **1200 series VICs** 216 217 5-tuple exact flow support for 1200 series adapters. This allows: 218 219 - Attributes: ingress 220 - Items: ipv4, ipv6, udp, tcp (must exactly match src/dst IP 221 addresses and ports and all must be specified) 222 - Actions: queue and void 223 - Selectors: 'is' 224 225- **1300 and later series VICS with advanced filters disabled** 226 227 With advanced filters disabled, an IPv4 or IPv6 item must be specified 228 in the pattern. 229 230 - Attributes: ingress 231 - Items: eth, vlan, ipv4, ipv6, udp, tcp, vxlan, inner eth, vlan, ipv4, ipv6, udp, tcp 232 - Actions: queue and void 233 - Selectors: 'is', 'spec' and 'mask'. 'last' is not supported 234 - In total, up to 64 bytes of mask is allowed across all headers 235 236- **1300 and later series VICS with advanced filters enabled** 237 238 - Attributes: ingress 239 - Items: eth, vlan, ipv4, ipv6, udp, tcp, vxlan, raw, inner eth, vlan, ipv4, ipv6, udp, tcp 240 - Actions: queue, mark, drop, flag, rss, passthru, and void 241 - Selectors: 'is', 'spec' and 'mask'. 'last' is not supported 242 - In total, up to 64 bytes of mask is allowed across all headers 243 244- **1400 and later series VICs with Flow Manager API enabled** 245 246 - Attributes: ingress, egress 247 - Items: eth, vlan, ipv4, ipv6, sctp, udp, tcp, vxlan, raw, inner eth, vlan, ipv4, ipv6, sctp, udp, tcp 248 - Ingress Actions: count, drop, flag, jump, mark, port_id, passthru, queue, rss, vxlan_decap, vxlan_encap, and void 249 - Egress Actions: count, drop, jump, passthru, vxlan_encap, and void 250 - Selectors: 'is', 'spec' and 'mask'. 'last' is not supported 251 - In total, up to 64 bytes of mask is allowed across all headers 252 253The VIC performs packet matching after applying VLAN strip. If VLAN 254stripping is enabled, EtherType in the ETH item corresponds to the 255stripped VLAN header's EtherType. Stripping does not affect the VLAN 256item. TCI and EtherType in the VLAN item are matched against those in 257the (stripped) VLAN header whether stripping is enabled or disabled. 258 259More features may be added in future firmware and new versions of the VIC. 260Please refer to the release notes. 261 262.. _overlay_offload: 263 264Overlay Offload 265--------------- 266 267Recent hardware models support overlay offload. When enabled, the NIC performs 268the following operations for VXLAN, NVGRE, and GENEVE packets. In all cases, 269inner and outer packets can be IPv4 or IPv6. 270 271- TSO for VXLAN and GENEVE packets. 272 273 Hardware supports NVGRE TSO, but DPDK currently has no NVGRE offload flags. 274 275- Tx checksum offloads. 276 277 The NIC fills in IPv4/UDP/TCP checksums for both inner and outer packets. 278 279- Rx checksum offloads. 280 281 The NIC validates IPv4/UDP/TCP checksums of both inner and outer packets. 282 Good checksum flags (e.g. ``PKT_RX_L4_CKSUM_GOOD``) indicate that the inner 283 packet has the correct checksum, and if applicable, the outer packet also 284 has the correct checksum. Bad checksum flags (e.g. ``PKT_RX_L4_CKSUM_BAD``) 285 indicate that the inner and/or outer packets have invalid checksum values. 286 287- Inner Rx packet type classification 288 289 PMD sets inner L3/L4 packet types (e.g. ``RTE_PTYPE_INNER_L4_TCP``), and 290 ``RTE_PTYPE_TUNNEL_GRENAT`` to indicate that the packet is tunneled. 291 PMD does not set L3/L4 packet types for outer packets. 292 293- Inner RSS 294 295 RSS hash calculation, therefore queue selection, is done on inner packets. 296 297In order to enable overlay offload, the 'Enable VXLAN' box should be checked 298via CIMC or UCSM followed by a reboot of the server. When PMD successfully 299enables overlay offload, it prints the following message on the console. 300 301.. code-block:: console 302 303 Overlay offload is enabled 304 305By default, PMD enables overlay offload if hardware supports it. To disable 306it, set ``devargs`` parameter ``disable-overlay=1``. For example:: 307 308 -a 12:00.0,disable-overlay=1 309 310By default, the NIC uses 4789 as the VXLAN port. The user may change 311it through ``rte_eth_dev_udp_tunnel_port_{add,delete}``. However, as 312the current NIC has a single VXLAN port number, the user cannot 313configure multiple port numbers. 314 315Geneve headers with non-zero options are not supported by default. To 316use Geneve with options, update the VIC firmware to the latest version 317and then set ``devargs`` parameter ``geneve-opt=1``. When Geneve with 318options is enabled, flow API cannot be used as the features are 319currently mutually exclusive. When this feature is successfully 320enabled, PMD prints the following message. 321 322.. code-block:: console 323 324 Geneve with options is enabled 325 326 327Ingress VLAN Rewrite 328-------------------- 329 330VIC adapters can tag, untag, or modify the VLAN headers of ingress 331packets. The ingress VLAN rewrite mode controls this behavior. By 332default, it is set to pass-through, where the NIC does not modify the 333VLAN header in any way so that the application can see the original 334header. This mode is sufficient for many applications, but may not be 335suitable for others. Such applications may change the mode by setting 336``devargs`` parameter ``ig-vlan-rewrite`` to one of the following. 337 338- ``pass``: Pass-through mode. The NIC does not modify the VLAN 339 header. This is the default mode. 340 341- ``priority``: Priority-tag default VLAN mode. If the ingress packet 342 is tagged with the default VLAN, the NIC replaces its VLAN header 343 with the priority tag (VLAN ID 0). 344 345- ``trunk``: Default trunk mode. The NIC tags untagged ingress packets 346 with the default VLAN. Tagged ingress packets are not modified. To 347 the application, every packet appears as tagged. 348 349- ``untag``: Untag default VLAN mode. If the ingress packet is tagged 350 with the default VLAN, the NIC removes or untags its VLAN header so 351 that the application sees an untagged packet. As a result, the 352 default VLAN becomes `untagged`. This mode can be useful for 353 applications such as OVS-DPDK performance benchmarks that utilize 354 only the default VLAN and want to see only untagged packets. 355 356 357Vectorized Rx Handler 358--------------------- 359 360ENIC PMD includes a version of the receive handler that is vectorized using 361AVX2 SIMD instructions. It is meant for bulk, throughput oriented workloads 362where reducing cycles/packet in PMD is a priority. In order to use the 363vectorized handler, take the following steps. 364 365- Use a recent version of gcc, icc, or clang and build 64-bit DPDK. If 366 the compiler is known to support AVX2, DPDK build system 367 automatically compiles the vectorized handler. Otherwise, the 368 handler is not available. 369 370- Set ``devargs`` parameter ``enable-avx2-rx=1`` to explicitly request that 371 PMD consider the vectorized handler when selecting the receive handler. 372 For example:: 373 374 -a 12:00.0,enable-avx2-rx=1 375 376 As the current implementation is intended for field trials, by default, the 377 vectorized handler is not considered (``enable-avx2-rx=0``). 378 379- Run on a UCS M4 or later server with CPUs that support AVX2. 380 381PMD selects the vectorized handler when the handler is compiled into 382the driver, the user requests its use via ``enable-avx2-rx=1``, CPU 383supports AVX2, and scatter Rx is not used. To verify that the 384vectorized handler is selected, enable debug logging 385(``--log-level=pmd,debug``) and check the following message. 386 387.. code-block:: console 388 389 enic_use_vector_rx_handler use the non-scatter avx2 Rx handler 390 39164B Completion Queue Entry 392-------------------------- 393 394Recent VIC adapters support 64B completion queue entries, as well as 39516B entries that are available on all adapter models. ENIC PMD enables 396and uses 64B entries by default, if available. 64B entries generally 397lower CPU cycles per Rx packet, as they avoid partial DMA writes and 398reduce cache contention between DMA and polling CPU. The effect is 399most pronounced when multiple Rx queues are used on Intel platforms 400with Data Direct I/O Technology (DDIO). 401 402If 64B entries are not available, PMD uses 16B entries. The user may 403explicitly disable 64B entries and use 16B entries by setting 404``devarg`` parameter ``cq64=0``. For example:: 405 406 -a 12:00.0,cq64=0 407 408To verify the selected entry size, enable debug logging 409(``--log-level=enic,debug``) and check the following messages. 410 411.. code-block:: console 412 413 PMD: rte_enic_pmd: Supported CQ entry sizes: 16 32 414 PMD: rte_enic_pmd: Using 16B CQ entry size 415 416.. _enic_limitations: 417 418Limitations 419----------- 420 421- **VLAN 0 Priority Tagging** 422 423 If a vNIC is configured in TRUNK mode by the UCS manager, the adapter will 424 priority tag egress packets according to 802.1Q if they were not already 425 VLAN tagged by software. If the adapter is connected to a properly configured 426 switch, there will be no unexpected behavior. 427 428 In test setups where an Ethernet port of a Cisco adapter in TRUNK mode is 429 connected point-to-point to another adapter port or connected though a router 430 instead of a switch, all ingress packets will be VLAN tagged. Programs such 431 as l3fwd may not account for VLAN tags in packets and may misbehave. One 432 solution is to enable VLAN stripping on ingress so the VLAN tag is removed 433 from the packet and put into the mbuf->vlan_tci field. Here is an example 434 of how to accomplish this: 435 436.. code-block:: console 437 438 vlan_offload = rte_eth_dev_get_vlan_offload(port); 439 vlan_offload |= ETH_VLAN_STRIP_OFFLOAD; 440 rte_eth_dev_set_vlan_offload(port, vlan_offload); 441 442Another alternative is modify the adapter's ingress VLAN rewrite mode so that 443packets with the default VLAN tag are stripped by the adapter and presented to 444DPDK as untagged packets. In this case mbuf->vlan_tci and the PKT_RX_VLAN and 445PKT_RX_VLAN_STRIPPED mbuf flags would not be set. This mode is enabled with the 446``devargs`` parameter ``ig-vlan-rewrite=untag``. For example:: 447 448 -a 12:00.0,ig-vlan-rewrite=untag 449 450- **SR-IOV** 451 452 - KVM hypervisor support only. VMware has not been tested. 453 - Requires VM-FEX, and so is only available on UCS managed servers connected 454 to Fabric Interconnects. It is not on standalone C-Series servers. 455 - VF devices are not usable directly from the host. They can only be used 456 as assigned devices on VM instances. 457 - Currently, unbind of the ENIC kernel mode driver 'enic.ko' on the VM 458 instance may hang. As a workaround, enic.ko should be blocked or removed 459 from the boot process. 460 - pci_generic cannot be used as the uio module in the VM. igb_uio or 461 vfio in non-IOMMU mode can be used. 462 - The number of RQs in UCSM dynamic vNIC configurations must be at least 2. 463 - The number of SR-IOV devices is limited to 256. Components on target system 464 might limit this number to fewer than 256. 465 466- **Flow API** 467 468 - The number of filters that can be specified with the Generic Flow API is 469 dependent on how many header fields are being masked. Use 'flow create' in 470 a loop to determine how many filters your VIC will support (not more than 471 1000 for 1300 series VICs). Filters are checked for matching in the order they 472 were added. Since there currently is no grouping or priority support, 473 'catch-all' filters should be added last. 474 - The supported range of IDs for the 'MARK' action is 0 - 0xFFFD. 475 - RSS and PASSTHRU actions only support "receive normally". They are limited 476 to supporting MARK + RSS and PASSTHRU + MARK to allow the application to mark 477 packets and then receive them normally. These require 1400 series VIC adapters 478 and latest firmware. 479 - RAW items are limited to matching UDP tunnel headers like VXLAN. 480 - For 1400 VICs, all flows using the RSS action on a port use same hash 481 configuration. The RETA is ignored. The queues used in the RSS group must be 482 sequential. There is a performance hit if the number of queues is not a power of 2. 483 Only level 0 (outer header) RSS is allowed. 484 485- **Statistics** 486 487 - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B). 488 This behavior applies to 1300 and older series VIC adapters. 489 1400 series VICs do not count CRC bytes, and count VLAN header only when VLAN 490 stripping is disabled. 491 - When the NIC drops a packet because the Rx queue has no free buffers, 492 ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or 493 VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping 494 is enabled. 495 This behavior applies to 1300 and older series VIC adapters. 1400 series VICs 496 do not increment this byte counter when packets are dropped. 497 498- **RSS Hashing** 499 500 - Hardware enables and disables UDP and TCP RSS hashing together. The driver 501 cannot control UDP and TCP hashing individually. 502 503How to build the suite 504---------------------- 505 506The build instructions for the DPDK suite should be followed. By default 507the ENIC PMD library will be built into the DPDK library. 508 509Refer to the document :ref:`compiling and testing a PMD for a NIC 510<pmd_build_and_test>` for details. 511 512For configuring and using UIO and VFIO frameworks, please refer to the 513documentation that comes with DPDK suite. 514 515Supported Cisco VIC adapters 516---------------------------- 517 518ENIC PMD supports all recent generations of Cisco VIC adapters including: 519 520- VIC 1200 series 521- VIC 1300 series 522- VIC 1400 series 523 524Supported Operating Systems 525--------------------------- 526 527Any Linux distribution fulfilling the conditions described in Dependencies 528section of DPDK documentation. 529 530Supported features 531------------------ 532 533- Unicast, multicast and broadcast transmission and reception 534- Receive queue polling 535- Port Hardware Statistics 536- Hardware VLAN acceleration 537- IP checksum offload 538- Receive side VLAN stripping 539- Multiple receive and transmit queues 540- Promiscuous mode 541- Setting RX VLAN (supported via UCSM/CIMC only) 542- VLAN filtering (supported via UCSM/CIMC only) 543- Execution of application by unprivileged system users 544- IPV4, IPV6 and TCP RSS hashing 545- UDP RSS hashing (1400 series and later adapters) 546- Scattered Rx 547- MTU update 548- SR-IOV on UCS managed servers connected to Fabric Interconnects 549- Flow API 550- Overlay offload 551 552 - Rx/Tx checksum offloads for VXLAN, NVGRE, GENEVE 553 - TSO for VXLAN and GENEVE packets 554 - Inner RSS 555 556Known bugs and unsupported features in this release 557--------------------------------------------------- 558 559- Signature or flex byte based flow direction 560- Drop feature of flow direction 561- VLAN based flow direction 562- Non-IPV4 flow direction 563- Setting of extended VLAN 564- MTU update only works if Scattered Rx mode is disabled 565- Maximum receive packet length is ignored if Scattered Rx mode is used 566 567Prerequisites 568------------- 569 570- Prepare the system as recommended by DPDK suite. This includes environment 571 variables, hugepages configuration, tool-chains and configuration. 572- Insert vfio-pci kernel module using the command 'modprobe vfio-pci' if the 573 user wants to use VFIO framework. 574- Insert uio kernel module using the command 'modprobe uio' if the user wants 575 to use UIO framework. 576- DPDK suite should be configured based on the user's decision to use VFIO or 577 UIO framework. 578- If the vNIC device(s) to be used is bound to the kernel mode Ethernet driver 579 use 'ip' to bring the interface down. The dpdk-devbind.py tool can 580 then be used to unbind the device's bus id from the ENIC kernel mode driver. 581- Bind the intended vNIC to vfio-pci in case the user wants ENIC PMD to use 582 VFIO framework using dpdk-devbind.py. 583- Bind the intended vNIC to igb_uio in case the user wants ENIC PMD to use 584 UIO framework using dpdk-devbind.py. 585 586At this point the system should be ready to run DPDK applications. Once the 587application runs to completion, the vNIC can be detached from vfio-pci or 588igb_uio if necessary. 589 590Root privilege is required to bind and unbind vNICs to/from VFIO/UIO. 591VFIO framework helps an unprivileged user to run the applications. 592For an unprivileged user to run the applications on DPDK and ENIC PMD, 593it may be necessary to increase the maximum locked memory of the user. 594The following command could be used to do this. 595 596.. code-block:: console 597 598 sudo sh -c "ulimit -l <value in Kilo Bytes>" 599 600The value depends on the memory configuration of the application, DPDK and 601PMD. Typically, the limit has to be raised to higher than 2GB. 602e.g., 2621440 603 604Additional Reference 605-------------------- 606 607- https://www.cisco.com/c/en/us/products/servers-unified-computing/index.html 608- https://www.cisco.com/c/en/us/products/interfaces-modules/unified-computing-system-adapters/index.html 609 610Contact Information 611------------------- 612 613Any questions or bugs should be reported to DPDK community and to the ENIC PMD 614maintainers: 615 616- John Daley <johndale@cisco.com> 617- Hyong Youb Kim <hyonkim@cisco.com> 618