doc: add RCU guide

[dpdk.git] / doc / guides / nics / szedata2.rst

diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index 4327e4e..a2092f9 100644 (file)
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -43,8 +43,10 @@ separately:
 
 *  **Kernel modules**
 
 
 *  **Kernel modules**
 

+   * combo6core

    * combov3
    * combov3

-   * szedata2_cv3
+   * szedata2
+   * szedata2_cv3 or szedata2_cv3_fdt

 
    Kernel modules manage initialization of hardware, allocation and
    sharing of resources for user space applications.
 
    Kernel modules manage initialization of hardware, allocation and
    sharing of resources for user space applications.


@@ -52,6 +54,15 @@ separately:
 Information about getting the dependencies can be found `here
 <http://www.netcope.com/en/company/community-support/dpdk-libsze2>`_.
 
 Information about getting the dependencies can be found `here
 <http://www.netcope.com/en/company/community-support/dpdk-libsze2>`_.
 

+Versions of the packages
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The minimum version of the provided packages:
+
+* for DPDK from 18.05: **4.4.1**
+
+* for DPDK up to 18.02 (including): **3.0.5**
+

 Configuration
 -------------
 
 Configuration
 -------------
 


@@ -62,45 +73,53 @@ These configuration options can be modified before compilation in the
 
    Value **y** enables compilation of szedata2 PMD.
 
 
    Value **y** enables compilation of szedata2 PMD.
 

-*  ``CONFIG_RTE_LIBRTE_PMD_SZEDATA2_AS`` default value: **0**
-
-   This option defines type of firmware address space and must be set
-   according to the used card and mode.
-   Currently supported values are:
-
-   * **0** - for cards (modes):
-
-      * NFB-100G1 (100G1)
+Using the SZEDATA2 PMD
+----------------------

 
 

-   * **1** - for cards (modes):
+From DPDK version 16.04 the type of SZEDATA2 PMD is changed to PMD_PDEV.
+SZEDATA2 device is automatically recognized during EAL initialization.
+No special command line options are needed.

 
 

-      * NFB-100G2Q (100G1)
+Kernel modules have to be loaded before running the DPDK application.

 
 

-   * **2** - for cards (modes):
+NFB card architecture
+---------------------

 
 

-      * NFB-40G2 (40G2)
-      * NFB-100G2C (100G2)
-      * NFB-100G2Q (40G2)
+The NFB cards are multi-port multi-queue cards, where (generally) data from any
+Ethernet port may be sent to any queue.
+They were historically represented in DPDK as a single port.

 
 

-   * **3** - for cards (modes):
+However, the new NFB-200G2QL card employs an addon cable which allows to connect
+it to two physical PCI-E slots at the same time (see the diagram below).
+This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
+bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
+throughput).

 
 

-      * NFB-40G2 (10G8)
-      * NFB-100G2Q (10G8)
+Since each slot may be connected to a different CPU and therefore to a different
+NUMA node, the card is represented as two ports in DPDK (each with half of the
+queues), which allows DPDK to work with data from the individual queues on the
+right NUMA node.

 
 

-   * **4** - for cards (modes):
+.. figure:: img/szedata2_nfb200g_architecture.*
+    :align: center

 
 

-      * NFB-100G1 (10G10)
+    NFB-200G2QL high-level diagram

 
 

-   * **5** - for experimental firmwares and future use
+Limitations
+-----------

 
 

-Using the SZEDATA2 PMD
-----------------------
+The SZEDATA2 PMD does not support operations related to Ethernet ports
+(link_up, link_down, set_mac_address, etc.).

 
 

-From DPDK version 16.04 the type of SZEDATA2 PMD is changed to PMD_PDEV.
-SZEDATA2 device is automatically recognized during EAL initialization.
-No special command line options are needed.
+NFB cards employ multiple Ethernet ports.
+Until now, Ethernet port-related operations were performed on all of them
+(since the whole card was represented as a single port).
+With NFB-200G2QL card, this is no longer viable (see above).

 
 

-Kernel modules have to be loaded before running the DPDK application.
+Since there is no fixed mapping between the queues and Ethernet ports, and since
+a single card can be represented as two ports in DPDK, there is no way of
+telling which (if any) physical ports should be associated with individual
+ports in DPDK.

 
 Example of usage
 ----------------
 
 Example of usage
 ----------------