Display information about dynamic device personalization (DDP) profile::
- testpmd> ddp get info (profile_patch)
+ testpmd> ddp get info (profile_path)
show vf stats
~~~~~~~~~~~~~
testpmd> clear vf stats (port_id) (vf_id)
+show port pctype mapping
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+List all items from the pctype mapping table::
+
+ testpmd> show port (port_id) pctype mapping
+
+
Configuration Functions
-----------------------
testpmd> tso show (port_id)
-gro
-~~~
+set port - gro
+~~~~~~~~~~~~~~
Enable or disable GRO in ``csum`` forwarding engine::
- testpmd> gro (on|off) (port_id)
+ testpmd> set port <port_id> gro on|off
If enabled, the csum forwarding engine will perform GRO on the TCP/IPv4
packets received from the given port.
.. 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.
+ will be performed GRO. After GRO, all merged packets have bad
+ checksums, since the GRO library doesn't re-calculate checksums for
+ the merged packets. Therefore, if users want the merged packets to
+ have correct checksums, please select HW IP checksum calculation and
+ HW TCP checksum calculation for the port which the merged packets are
+ transmitted to.
+
+show port - gro
+~~~~~~~~~~~~~~~
-gro set
-~~~~~~~
+Display GRO configuration for a given port::
+
+ testpmd> show port <port_id> gro
+
+set gro flush
+~~~~~~~~~~~~~
+
+Set the cycle to flush the GROed packets from reassembly tables::
+
+ testpmd> set gro flush <cycles>
+
+When enable GRO, the csum forwarding engine performs GRO on received
+packets, and the GROed packets are stored in reassembly tables. Users
+can use this command to determine when the GROed packets are flushed
+from the reassembly tables.
+
+The ``cycles`` is measured in GRO operation times. The csum forwarding
+engine flushes the GROed packets from the tables every ``cycles`` GRO
+operations.
+
+By default, the value of ``cycles`` is 1, which means flush GROed packets
+from the reassembly tables as soon as one GRO operation finishes. The value
+of ``cycles`` should be in the range of 1 to ``GRO_MAX_FLUSH_CYCLES``.
+
+Please note that the large value of ``cycles`` may cause the poor TCP/IP
+stack performance. Because the GROed packets are delayed to arrive the
+stack, thus causing more duplicated ACKs and TCP retransmissions.
+
+set port - gso
+~~~~~~~~~~~~~~
+
+Toggle per-port GSO support in ``csum`` forwarding engine::
+
+ testpmd> set port <port_id> gso on|off
+
+If enabled, the csum forwarding engine will perform GSO on supported IPv4
+packets, transmitted on the given port.
+
+If disabled, packets transmitted on the given port will not undergo GSO.
+By default, GSO is disabled for all ports.
+
+.. note::
+
+ When GSO is enabled on a port, supported IPv4 packets transmitted on that
+ port undergo GSO. Afterwards, the segmented packets are represented by
+ multi-segment mbufs; however, the csum forwarding engine doesn't calculation
+ of checksums for GSO'd segments in SW. As a result, if users want correct
+ checksums in GSO segments, they should enable HW checksum calculation for
+ GSO-enabled ports.
-Set max flow number and max packet number per-flow for GRO::
+ For example, HW checksum calculation for VxLAN GSO'd packets may be enabled
+ by setting the following options in the csum forwarding engine:
- testpmd> gro set (max_flow_num) (max_item_num_per_flow) (port_id)
+ testpmd> csum set outer_ip hw <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.
+ testpmd> csum set ip hw <port_id>
-If current packet number is greater than or equal to the max value, GRO
-will stop processing incoming packets.
+ testpmd> csum set tcp hw <port_id>
+
+set gso segsz
+~~~~~~~~~~~~~
+
+Set the maximum GSO segment size (measured in bytes), which includes the
+packet header and the packet payload for GSO-enabled ports (global)::
+
+ testpmd> set gso segsz <length>
+
+show port - gso
+~~~~~~~~~~~~~~~
+
+Display the status of Generic Segmentation Offload for a given port::
+
+ testpmd> show port <port_id> gso
mac_addr add
~~~~~~~~~~~~
testpmd> port config (port_id|all) l2-tunnel E-tag (enable|disable)
+port config pctype mapping
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Reset pctype mapping table::
+
+ testpmd> port config (port_id) pctype mapping reset
+
+Update hardware defined pctype to software defined flow type mapping table::
+
+ testpmd> port config (port_id) pctype mapping update (pctype_id_0[,pctype_id_1]*) (flow_type_id)
+
+where:
+
+* ``pctype_id_x``: hardware pctype id as index of bit in bitmask value of the pctype mapping table.
+
+* ``flow_type_id``: software flow type id as the index of the pctype mapping table.
+
Link Bonding Functions
----------------------
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
+set bonding agg_mode
+~~~~~~~~~~~~~~~~~~~~
+
+Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+
+ testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
+
+
show bonding config
~~~~~~~~~~~~~~~~~~~
- ``thresh {unsigned}``: accuracy threshold.
+- ``gtp``, ``gtpc``, ``gtpu``: match GTPv1 header.
+
+ - ``teid {unsigned}``: tunnel endpoint identifier.
+
Actions list
^^^^^^^^^^^^
git.droids-corp.org / dpdk.git / blobdiff