======================
The ice PMD (librte_pmd_ice) provides poll mode driver support for
-10/25 Gbps Intel® Ethernet 810 Series Network Adapters based on
+10/25/50/100 Gbps Intel® Ethernet 810 Series Network Adapters based on
the Intel Ethernet Controller E810.
Prerequisites
-------------
-- Identifying your adapter using `Intel Support
- <http://www.intel.com/support>`_ and get the latest NVM/FW images.
-
- Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup the basic DPDK environment.
- To get better performance on Intel platforms, please follow the "How to get best performance with NICs on Intel platforms"
section of the :ref:`Getting Started Guide for Linux <linux_gsg>`.
-
Pre-Installation Configuration
------------------------------
Toggle display of generic debugging messages.
-- ``CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC`` (default ``y``)
-
- Toggle bulk allocation for RX.
-
- ``CONFIG_RTE_LIBRTE_ICE_16BYTE_RX_DESC`` (default ``n``)
Toggle to use a 16-byte RX descriptor, by default the RX descriptor is 32 byte.
NOTE: In Safe mode, only very limited features are available, features like RSS,
checksum, fdir, tunneling ... are all disabled.
+- ``Generic Flow Pipeline Mode Support`` (default ``0``)
+
+ In pipeline mode, a flow can be set at one specific stage by setting parameter
+ ``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
+ priority 0 located at the first pipeline stage which typically be used as a firewall
+ to drop the packet on a blacklist(we called it permission stage). At this stage,
+ flow rules are created for the device's exact match engine: switch. Flows with priority
+ !0 located at the second stage, typically packets are classified here and be steered to
+ specific queue or queue group (we called it distribution stage), At this stage, flow
+ rules are created for device's flow director engine.
+ For none-pipeline mode, ``priority`` is ignored, a flow rule can be created as a flow director
+ rule or a switch rule depends on its pattern/action and the resource allocation situation,
+ all flows are virtually at the same pipeline stage.
+ By default, generic flow API is enabled in none-pipeline mode, user can choose to
+ use pipeline mode by setting ``devargs`` parameter ``pipeline-mode-support``,
+ for example::
+
+ -w 80:00.0,pipeline-mode-support=1
+
- ``Protocol extraction for per queue``
- Configure the RX queues to do protocol extraction into ``rte_mbuf::udata64``
- for protocol handling acceleration, like checking the TCP SYN packets quickly.
+ Configure the RX queues to do protocol extraction into mbuf for protocol
+ handling acceleration, like checking the TCP SYN packets quickly.
The argument format is::
The grouping ``()`` can be omitted for single element group. If no queues are
specified, PMD will use this protocol extraction type for all queues.
- Protocol is : ``vlan, ipv4, ipv6, ipv6_flow, tcp``.
+ Protocol is : ``vlan, ipv4, ipv6, ipv6_flow, tcp, ip_offset``.
.. code-block:: console
This setting means queues 1, 2-3, 8-9 are TCP extraction, queues 10-23 are
IPv6 extraction, other queues use the default VLAN extraction.
- The extraction will be copied into the lower 32 bit of ``rte_mbuf::udata64``.
+ The extraction metadata is copied into the registered dynamic mbuf field, and
+ the related dynamic mbuf flags is set.
.. table:: Protocol extraction : ``vlan``
TCPHDR2 - Reserved
- Use ``get_proto_xtr_flds(struct rte_mbuf *mb)`` to access the protocol
- extraction, do not use ``rte_mbuf::udata64`` directly.
+ .. table:: Protocol extraction : ``ip_offset``
+
+ +----------------------------+----------------------------+
+ | IPHDR2 | IPHDR1 |
+ +============================+============================+
+ | IPv6 HDR Offset | IPv4 HDR Offset |
+ +----------------------------+----------------------------+
- The ``dump_proto_xtr_flds(struct rte_mbuf *mb)`` routine shows how to
+ IPHDR1 - Outer/Single IPv4 Header offset.
+
+ IPHDR2 - Outer/Single IPv6 Header offset.
+
+ Use ``rte_net_ice_dynf_proto_xtr_metadata_get`` to access the protocol
+ extraction metadata, and use ``RTE_PKT_RX_DYNF_PROTO_XTR_*`` to get the
+ metadata type of ``struct rte_mbuf::ol_flags``.
+
+ The ``rte_net_ice_dump_proto_xtr_metadata`` routine shows how to
access the protocol extraction result in ``struct rte_mbuf``.
Driver compilation and testing
The APPs based on DPDK should avoid providing such packets.
+Device Config Function (DCF)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section demonstrates ICE DCF PMD, which shares the core module with ICE
+PMD and iAVF PMD.
+
+A DCF (Device Config Function) PMD bounds to the device's trusted VF with ID 0,
+it can act as a sole controlling entity to exercise advance functionality (such
+as switch, ACL) for the rest VFs.
+
+The DCF PMD needs to advertise and acquire DCF capability which allows DCF to
+send AdminQ commands that it would like to execute over to the PF and receive
+responses for the same from PF.
+
+.. _figure_ice_dcf:
+
+.. figure:: img/ice_dcf.*
+
+ DCF Communication flow.
+
+#. Create the VFs::
+
+ echo 4 > /sys/bus/pci/devices/0000\:18\:00.0/sriov_numvfs
+
+#. Enable the VF0 trust on::
+
+ ip link set dev enp24s0f0 vf 0 trust on
+
+#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
+
+ testpmd -l 22-25 -n 4 -w 18:01.0,cap=dcf -- -i
+
+#. Monitor the VF2 interface network traffic::
+
+ tcpdump -e -nn -i enp24s1f2
+
+#. Create one flow to redirect the traffic to VF2 by DCF::
+
+ flow create 0 priority 0 ingress pattern eth / ipv4 src is 192.168.0.2 \
+ dst is 192.168.0.3 / end actions vf id 2 / end
+
+#. Send the packet, and it should be displayed on tcpdump::
+
+ sendp(Ether(src='3c:fd:fe:aa:bb:78', dst='00:00:00:01:02:03')/IP(src=' \
+ 192.168.0.2', dst="192.168.0.3")/TCP(flags='S')/Raw(load='XXXXXXXXXX'), \
+ iface="enp24s0f0", count=10)
+
Sample Application Notes
------------------------
A symbolic link to the DDP package file is also ok. The same package
file is used by both the kernel driver and the DPDK PMD.
-
-19.02 limitation
-~~~~~~~~~~~~~~~~
-
-Ice code released in 19.02 is for evaluation only.
git.droids-corp.org / dpdk.git / blobdiff