+- ``Safe Mode Support`` (default ``0``)
+
+ If driver failed to load OS package, by default driver's initialization failed.
+ But if user intend to use the device without OS package, user can take ``devargs``
+ parameter ``safe-mode-support``, for example::
+
+ -w 80:00.0,safe-mode-support=1
+
+ Then the driver will be initialized successfully and the device will enter Safe Mode.
+ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -w 80:00.0,flow-mark-support=1
+
+- ``Protocol extraction for per queue``
+
+ 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::
+
+ -w 18:00.0,proto_xtr=<queues:protocol>[<queues:protocol>...]
+ -w 18:00.0,proto_xtr=<protocol>
+
+ Queues are grouped by ``(`` and ``)`` within the group. The ``-`` character
+ is used as a range separator and ``,`` is used as a single number separator.
+ 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``.
+
+ .. code-block:: console
+
+ testpmd -w 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
+
+ This setting means queues 1, 2-3, 8-9 are TCP extraction, queues 10-13 are
+ VLAN extraction, other queues run with no protocol extraction.
+
+ .. code-block:: console
+
+ testpmd -w 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
+
+ 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 metadata is copied into the registered dynamic mbuf field, and
+ the related dynamic mbuf flags is set.
+
+ .. table:: Protocol extraction : ``vlan``
+
+ +----------------------------+----------------------------+
+ | VLAN2 | VLAN1 |
+ +======+===+=================+======+===+=================+
+ | PCP | D | VID | PCP | D | VID |
+ +------+---+-----------------+------+---+-----------------+