doc: add cryptodev sample code
[dpdk.git] / doc / guides / testpmd_app_ug / testpmd_funcs.rst
index efb697e..e5a38cf 100644 (file)
@@ -119,6 +119,22 @@ practical or possible testpmd supports alternative methods for executing command
    testpmd>
 
 
+* At run-time additional commands can be loaded in bulk by invoking the ``load FILENAME``
+  command.
+
+.. code-block:: console
+
+   testpmd> load /home/ubuntu/flow-create-commands.txt
+   Flow rule #0 created
+   Flow rule #1 created
+   ...
+   ...
+   Flow rule #498 created
+   Flow rule #499 created
+   Read all CLI commands from /home/ubuntu/flow-create-commands.txt
+   testpmd>
+
+
 In all cases output from any included command will be displayed as standard output.
 Execution will continue until the end of the file is reached regardless of
 whether any errors occur.  The end user must examine the output to determine if
@@ -364,6 +380,20 @@ For example::
    testpmd> read txd 0 0 4
         0x00000001 - 0x24C3C440 / 0x000F0000 - 0x2330003C
 
+ddp get list
+~~~~~~~~~~~~
+
+Get loaded dynamic device personalization (DDP) package info list::
+
+   testpmd> ddp get list (port_id)
+
+ddp get info
+~~~~~~~~~~~~
+
+Display information about dynamic device personalization (DDP) profile::
+
+   testpmd> ddp get info (profile_patch)
+
 show vf stats
 ~~~~~~~~~~~~~
 
@@ -868,6 +898,40 @@ Display the status of TCP Segmentation Offload::
 
    testpmd> tso show (port_id)
 
+gro
+~~~
+
+Enable or disable GRO in ``csum`` forwarding engine::
+
+   testpmd> gro (on|off) (port_id)
+
+If enabled, the csum forwarding engine will perform GRO on the TCP/IPv4
+packets received from the given port.
+
+If disabled, packets received from the given port won't be performed
+GRO. By default, GRO is disabled for all ports.
+
+.. note::
+
+   When enable GRO for a port, TCP/IPv4 packets received from the port
+   will be performed GRO. After GRO, the merged packets are multi-segments.
+   But csum forwarding engine doesn't support to calculate TCP checksum
+   for multi-segment packets in SW. So please select TCP HW checksum
+   calculation for the port which GROed packets are transmitted to.
+
+gro set
+~~~~~~~
+
+Set max flow number and max packet number per-flow for GRO::
+
+   testpmd> gro set (max_flow_num) (max_item_num_per_flow) (port_id)
+
+The product of ``max_flow_num`` and ``max_item_num_per_flow`` is the max
+number of packets a GRO table can store.
+
+If current packet number is greater than or equal to the max value, GRO
+will stop processing incoming packets.
+
 mac_addr add
 ~~~~~~~~~~~~
 
@@ -1195,6 +1259,20 @@ Add an E-tag forwarding filter on a port::
 Delete an E-tag forwarding filter on a port::
    testpmd> E-tag set filter del e-tag-id (value) port (port_id)
 
+ddp add
+~~~~~~~
+
+Load a dynamic device personalization (DDP) package::
+
+   testpmd> ddp add (port_id) (package_path[,output_path])
+
+ddp del
+~~~~~~~
+
+Delete a dynamic device personalization package::
+
+   testpmd> ddp del (port_id) (package_path)
+
 ptype mapping
 ~~~~~~~~~~~~~
 
@@ -1722,6 +1800,15 @@ For example, to set the link status monitoring polling period of bonded device (
    testpmd> set bonding mon_period 5 150
 
 
+set bonding lacp dedicated_queue
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
+when in mode 4 (link-aggregration-802.3ad)::
+
+   testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
+
+
 show bonding config
 ~~~~~~~~~~~~~~~~~~~
 
@@ -2248,7 +2335,8 @@ Flow rules management
 ---------------------
 
 Control of the generic flow API (*rte_flow*) is fully exposed through the
-``flow`` command (validation, creation, destruction and queries).
+``flow`` command (validation, creation, destruction, queries and operation
+modes).
 
 Considering *rte_flow* overlaps with all `Filter Functions`_, using both
 features simultaneously may cause undefined side-effects and is therefore
@@ -2302,6 +2390,10 @@ following sections.
 
    flow list {port_id} [group {group_id}] [...]
 
+- Restrict ingress traffic to the defined flow rules::
+
+   flow isolate {port_id} {boolean}
+
 Validating flow rules
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -2592,6 +2684,10 @@ This section lists supported pattern items and their attributes, if any.
 
   - ``protocol {unsigned}``: protocol type.
 
+- ``fuzzy``: fuzzy pattern match, expect faster than default.
+
+  - ``thresh {unsigned}``: accuracy threshold.
+
 Actions list
 ^^^^^^^^^^^^
 
@@ -2878,19 +2974,72 @@ Output can be limited to specific groups::
    7       63      0       i-      ETH IPV6 UDP VXLAN => MARK QUEUE
    testpmd>
 
+Toggling isolated mode
+~~~~~~~~~~~~~~~~~~~~~~
+
+``flow isolate`` can be used to tell the underlying PMD that ingress traffic
+must only be injected from the defined flow rules; that no default traffic
+is expected outside those rules and the driver is free to assign more
+resources to handle them. It is bound to ``rte_flow_isolate()``::
+
+ flow isolate {port_id} {boolean}
+
+If successful, enabling or disabling isolated mode shows either::
+
+ Ingress traffic on port [...]
+    is now restricted to the defined flow rules
+
+Or::
+
+ Ingress traffic on port [...]
+    is not restricted anymore to the defined flow rules
+
+Otherwise, in case of error::
+
+   Caught error type [...] ([...]): [...]
+
+Mainly due to its side effects, PMDs supporting this mode may not have the
+ability to toggle it more than once without reinitializing affected ports
+first (e.g. by exiting testpmd).
+
+Enabling isolated mode::
+
+ testpmd> flow isolate 0 true
+ Ingress traffic on port 0 is now restricted to the defined flow rules
+ testpmd>
+
+Disabling isolated mode::
+
+ testpmd> flow isolate 0 false
+ Ingress traffic on port 0 is not restricted anymore to the defined flow rules
+ testpmd>
+
 Sample QinQ flow rules
 ~~~~~~~~~~~~~~~~~~~~~~
 
+Before creating QinQ rule(s) the following commands should be issued to enable QinQ::
+
+   testpmd> port stop 0
+   testpmd> vlan set qinq on 0
+
+The above command sets the inner and outer TPID's to 0x8100.
+
+To change the TPID's the following commands should be used::
+
+   testpmd> vlan set outer tpid 0xa100 0
+   testpmd> vlan set inner tpid 0x9100 0
+   testpmd> port start 0
+
 Validate and create a QinQ rule on port 0 to steer traffic to a VF queue in a VM.
 
 ::
 
-   testpmd> flow validate 0 ingress pattern eth / vlan tpid is 0x8100 tci is 4 /
-       vlan tpid is 0x8100 tci is 5 / end actions vf id 1 / queue index 0 / end
+   testpmd> flow validate 0 ingress pattern eth / vlan tci is 123 /
+       vlan tci is 456 / end actions vf id 1 / queue index 0 / end
    Flow rule #0 validated
 
-   testpmd> flow create 0 ingress pattern eth / vlan tpid is 0x8100 tci is 4 /
-       vlan tpid is 0x8100 tci is 5 / end actions vf id 1 / queue index 0 / end
+   testpmd> flow create 0 ingress pattern eth / vlan tci is 4 /
+       vlan tci is 456 / end actions vf id 123 / queue index 0 / end
    Flow rule #0 created
 
    testpmd> flow list 0
@@ -2901,20 +3050,15 @@ Validate and create a QinQ rule on port 0 to steer traffic to a queue on the hos
 
 ::
 
-   testpmd> flow validate 0 ingress pattern eth / vlan tpid is 0x8100 tci is 6 /
-        vlan tpid is 0x8100 tci is 7 / end actions pf / queue index 0 / end
+   testpmd> flow validate 0 ingress pattern eth / vlan tci is 321 /
+        vlan tci is 654 / end actions pf / queue index 0 / end
    Flow rule #1 validated
 
-   testpmd> flow create 0 ingress pattern eth / vlan tpid is 0x8100 tci is 6 /
-        vlan tpid is 0x8100 tci is 7 / end actions pf / queue index 1 / end
+   testpmd> flow create 0 ingress pattern eth / vlan tci is 321 /
+        vlan tci is 654 / end actions pf / queue index 1 / end
    Flow rule #1 created
 
    testpmd> flow list 0
    ID      Group   Prio    Attr    Rule
    0       0       0       i-      ETH VLAN VLAN=>VF QUEUE
    1       0       0       i-      ETH VLAN VLAN=>PF QUEUE
-
-After creating QinQ rule(s) the following command should be issued to enable QinQ::
-
-   testpmd> vlan set qinq on 0
-