Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/18225/?format=api
{ "id": 18225, "url": "https://patches.dpdk.org/api/patches/18225/?format=api", "web_url": "https://patches.dpdk.org/project/dpdk/patch/fcc4d34589201dc8b64fb94bb71c04005b8a5a5a.1482168851.git.adrien.mazarguil@6wind.com/", "project": { "id": 1, "url": "https://patches.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<fcc4d34589201dc8b64fb94bb71c04005b8a5a5a.1482168851.git.adrien.mazarguil@6wind.com>", "list_archive_url": "https://inbox.dpdk.org/dev/fcc4d34589201dc8b64fb94bb71c04005b8a5a5a.1482168851.git.adrien.mazarguil@6wind.com", "date": "2016-12-19T17:49:15", "name": "[dpdk-dev,v3,25/25] doc: describe testpmd flow command", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": true, "hash": "520decf105c21802b5143a43c70a4d254ae4159a", "submitter": { "id": 165, "url": "https://patches.dpdk.org/api/people/165/?format=api", "name": "Adrien Mazarguil", "email": "adrien.mazarguil@6wind.com" }, "delegate": null, "mbox": "https://patches.dpdk.org/project/dpdk/patch/fcc4d34589201dc8b64fb94bb71c04005b8a5a5a.1482168851.git.adrien.mazarguil@6wind.com/mbox/", "series": [], "comments": "https://patches.dpdk.org/api/patches/18225/comments/", "check": "success", "checks": "https://patches.dpdk.org/api/patches/18225/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 536B1FB64;\n\tMon, 19 Dec 2016 18:51:00 +0100 (CET)", "from mail-wj0-f174.google.com (mail-wj0-f174.google.com\n\t[209.85.210.174]) by dpdk.org (Postfix) with ESMTP id C5626FAB9\n\tfor <dev@dpdk.org>; Mon, 19 Dec 2016 18:50:21 +0100 (CET)", "by mail-wj0-f174.google.com with SMTP id v7so156364771wjy.2\n\tfor <dev@dpdk.org>; Mon, 19 Dec 2016 09:50:21 -0800 (PST)", "from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net.\n\t[82.239.227.177]) by smtp.gmail.com with ESMTPSA id\n\t197sm18201335wmy.16.2016.12.19.09.50.18\n\tfor <dev@dpdk.org> (version=TLS1_2 cipher=AES128-SHA bits=128/128);\n\tMon, 19 Dec 2016 09:50:20 -0800 (PST)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=6wind-com.20150623.gappssmtp.com; s=20150623;\n\th=from:to:subject:date:message-id:in-reply-to:references;\n\tbh=GATf+rtD9YPNDsxQ7yW1dVnPmegXgfu2da1VK3KjItY=;\n\tb=lRWBSbxRcYlufKPYH7NHJOlXA8W4SsD6cuSse5Qa7WcHw5QqEOIxHMtxQSLZS2RlYK\n\tQvfrf4G05s2lvZZbTyQbbw2TfTdwbleb/Ur2HKSjYSb/FpAqDkgscQeP0fhTmUKJpKy9\n\tF9hoMCaIAnSd6a2arwP0NmKxYGs1hIefhqre9nDh6J1vKzMnXegOQz3BeQ92cjXXS+L0\n\tRKMnwBNDBImOVt9Wjz4X7eex5nGAxJHZCrhwriDPkp0DRFTreuVJhro5o+MqEhzLLSLs\n\t0oKWZQS49WisPtAAkRn/XvG3HYaI3XI/fPELmIY6YrQNlJZKogdiwS/MhnDHhvAQJvpp\n\tTw4g==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:subject:date:message-id:in-reply-to\n\t:references;\n\tbh=GATf+rtD9YPNDsxQ7yW1dVnPmegXgfu2da1VK3KjItY=;\n\tb=ma/H6JwwfTgNuFvznvA/+VfSoVoI4Quvi4p4Y0nu6x9dGudT9bmuXPj2jr0ozN7gcI\n\tcCU5NiRIIFbHmqDD+2URqjnCByKuxvnjoVXI+LSq37vx5uLPIfSR/LLH9SR5qxOHHyK3\n\to7LS9SyosRZRcOkTWOf4iZZQoR2OGvdSYS2BDTAAZtZtVX1qNldl9w8F6be62gbJipxM\n\t2xx8nciunWZV5VpsCpe117u5n6QJZemaf0/gM5rtNZYB/5G2sbR1O6PW25Wyw3TOwH2n\n\tHArPyFBUQ+uU/7KCTvQ1m+SWqjSc3TKo6y6d+8Y/o+Ipn7Te7oFdP20mmy+ToWPw5W6x\n\tYcjw==", "X-Gm-Message-State": "AIkVDXJzOnUrwdcxPejsW6aj9ahUrbEKOroPutnOyKJoraeDvdC10sRTNNfG4GCwDZ27FDzN", "X-Received": "by 10.194.80.42 with SMTP id o10mr17691561wjx.65.1482169820820; \n\tMon, 19 Dec 2016 09:50:20 -0800 (PST)", "From": "Adrien Mazarguil <adrien.mazarguil@6wind.com>", "To": "dev@dpdk.org", "Date": "Mon, 19 Dec 2016 18:49:15 +0100", "Message-Id": "<fcc4d34589201dc8b64fb94bb71c04005b8a5a5a.1482168851.git.adrien.mazarguil@6wind.com>", "X-Mailer": "git-send-email 2.1.4", "In-Reply-To": "<cover.1482168851.git.adrien.mazarguil@6wind.com>", "References": "<cover.1481903839.git.adrien.mazarguil@6wind.com>\n\t<cover.1482168851.git.adrien.mazarguil@6wind.com>", "Subject": "[dpdk-dev] [PATCH v3 25/25] doc: describe testpmd flow command", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "Document syntax, interaction with rte_flow and provide usage examples.\n\nSigned-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>\nAcked-by: Olga Shern <olgas@mellanox.com>\n---\n doc/guides/testpmd_app_ug/testpmd_funcs.rst | 612 +++++++++++++++++++++++\n 1 file changed, 612 insertions(+)", "diff": "diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst\nindex f1c269a..50cba16 100644\n--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst\n+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst\n@@ -1631,6 +1631,9 @@ Filter Functions\n \n This section details the available filter functions that are available.\n \n+Note these functions interface the deprecated legacy filtering framework,\n+superseded by *rte_flow*. See `Flow rules management`_.\n+\n ethertype_filter\n ~~~~~~~~~~~~~~~~~~~~\n \n@@ -2041,3 +2044,612 @@ Set different GRE key length for input set::\n For example to set GRE key length for input set to 4 bytes on port 0::\n \n testpmd> global_config 0 gre-key-len 4\n+\n+\n+.. _testpmd_rte_flow:\n+\n+Flow rules management\n+---------------------\n+\n+Control of the generic flow API (*rte_flow*) is fully exposed through the\n+``flow`` command (validation, creation, destruction and queries).\n+\n+Considering *rte_flow* overlaps with all `Filter Functions`_, using both\n+features simultaneously may cause undefined side-effects and is therefore\n+not recommended.\n+\n+``flow`` syntax\n+~~~~~~~~~~~~~~~\n+\n+Because the ``flow`` command uses dynamic tokens to handle the large number\n+of possible flow rules combinations, its behavior differs slightly from\n+other commands, in particular:\n+\n+- Pressing *?* or the *<tab>* key displays contextual help for the current\n+ token, not that of the entire command.\n+\n+- Optional and repeated parameters are supported (provided they are listed\n+ in the contextual help).\n+\n+The first parameter stands for the operation mode. Possible operations and\n+their general syntax are described below. They are covered in detail in the\n+following sections.\n+\n+- Check whether a flow rule can be created::\n+\n+ flow validate {port_id}\n+ [group {group_id}] [priority {level}] [ingress] [egress]\n+ pattern {item} [/ {item} [...]] / end\n+ actions {action} [/ {action} [...]] / end\n+\n+- Create a flow rule::\n+\n+ flow create {port_id}\n+ [group {group_id}] [priority {level}] [ingress] [egress]\n+ pattern {item} [/ {item} [...]] / end\n+ actions {action} [/ {action} [...]] / end\n+\n+- Destroy specific flow rules::\n+\n+ flow destroy {port_id} rule {rule_id} [...]\n+\n+- Destroy all flow rules::\n+\n+ flow flush {port_id}\n+\n+- Query an existing flow rule::\n+\n+ flow query {port_id} {rule_id} {action}\n+\n+- List existing flow rules sorted by priority, filtered by group\n+ identifiers::\n+\n+ flow list {port_id} [group {group_id}] [...]\n+\n+Validating flow rules\n+~~~~~~~~~~~~~~~~~~~~~\n+\n+``flow validate`` reports whether a flow rule would be accepted by the\n+underlying device in its current state but stops short of creating it. It is\n+bound to ``rte_flow_validate()``::\n+\n+ flow validate {port_id}\n+ [group {group_id}] [priority {level}] [ingress] [egress]\n+ pattern {item} [/ {item} [...]] / end\n+ actions {action} [/ {action} [...]] / end\n+\n+If successful, it will show::\n+\n+ Flow rule validated\n+\n+Otherwise it will show an error message of the form::\n+\n+ Caught error type [...] ([...]): [...]\n+\n+This command uses the same parameters as ``flow create``, their format is\n+described in `Creating flow rules`_.\n+\n+Check whether redirecting any Ethernet packet received on port 0 to RX queue\n+index 6 is supported::\n+\n+ testpmd> flow validate 1 ingress pattern eth / end\n+ actions queue index 6 / end\n+ Flow rule validated\n+ testpmd>\n+\n+Port 0 does not support TCPv6 rules::\n+\n+ testpmd> flow validate 0 ingress pattern eth / ipv6 / tcp / end\n+ actions drop / end\n+ Caught error type 9 (specific pattern item): Invalid argument.\n+ testpmd>\n+\n+Creating flow rules\n+~~~~~~~~~~~~~~~~~~~\n+\n+``flow create`` validates and creates the specified flow rule. It is bound\n+to ``rte_flow_create()``::\n+\n+ flow create {port_id}\n+ [group {group_id}] [priority {level}] [ingress] [egress]\n+ pattern {item} [/ {item} [...]] / end\n+ actions {action} [/ {action} [...]] / end\n+\n+If successful, it will return a flow rule ID usable with other commands::\n+\n+ Flow rule #[...] created\n+\n+Otherwise it will show an error message of the form::\n+\n+ Caught error type [...] ([...]): [...]\n+\n+Parameters describe in the following order:\n+\n+- Attributes (*group*, *priority*, *ingress*, *egress* tokens).\n+- A matching pattern, starting with the *pattern* token and terminated by an\n+ *end* pattern item.\n+- Actions, starting with the *actions* token and terminated by an *end*\n+ action.\n+\n+These translate directly to *rte_flow* objects provided as-is to the\n+underlying functions.\n+\n+The shortest valid definition only comprises mandatory tokens::\n+\n+ testpmd> flow create 0 pattern end actions end\n+\n+Note that PMDs may refuse rules that essentially do nothing such as this\n+one.\n+\n+**All unspecified object values are automatically initialized to 0.**\n+\n+Attributes\n+^^^^^^^^^^\n+\n+These tokens affect flow rule attributes (``struct rte_flow_attr``) and are\n+specified before the ``pattern`` token.\n+\n+- ``group {group id}``: priority group.\n+- ``priority {level}``: priority level within group.\n+- ``ingress``: rule applies to ingress traffic.\n+- ``egress``: rule applies to egress traffic.\n+\n+Each instance of an attribute specified several times overrides the previous\n+value as shown below (group 4 is used)::\n+\n+ testpmd> flow create 0 group 42 group 24 group 4 [...]\n+\n+Note that once enabled, ``ingress`` and ``egress`` cannot be disabled.\n+\n+While not specifying a direction is an error, some rules may allow both\n+simultaneously.\n+\n+Most rules affect RX therefore contain the ``ingress`` token::\n+\n+ testpmd> flow create 0 ingress pattern [...]\n+\n+Matching pattern\n+^^^^^^^^^^^^^^^^\n+\n+A matching pattern starts after the ``pattern`` token. It is made of pattern\n+items and is terminated by a mandatory ``end`` item.\n+\n+Items are named after their type (*RTE_FLOW_ITEM_TYPE_* from ``enum\n+rte_flow_item_type``).\n+\n+The ``/`` token is used as a separator between pattern items as shown\n+below::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end [...]\n+\n+Note that protocol items like these must be stacked from lowest to highest\n+layer to make sense. For instance, the following rule is either invalid or\n+unlikely to match any packet::\n+\n+ testpmd> flow create 0 ingress pattern eth / udp / ipv4 / end [...]\n+\n+More information on these restrictions can be found in the *rte_flow*\n+documentation.\n+\n+Several items support additional specification structures, for example\n+``ipv4`` allows specifying source and destination addresses as follows::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.1.1.1\n+ dst is 10.2.0.0 / end [...]\n+\n+This rule matches all IPv4 traffic with the specified properties.\n+\n+In this example, ``src`` and ``dst`` are field names of the underlying\n+``struct rte_flow_item_ipv4`` object. All item properties can be specified\n+in a similar fashion.\n+\n+The ``is`` token means that the subsequent value must be matched exactly,\n+and assigns ``spec`` and ``mask`` fields in ``struct rte_flow_item``\n+accordingly. Possible assignment tokens are:\n+\n+- ``is``: match value perfectly (with full bit-mask).\n+- ``spec``: match value according to configured bit-mask.\n+- ``last``: specify upper bound to establish a range.\n+- ``mask``: specify bit-mask with relevant bits set to one.\n+- ``prefix``: generate bit-mask from a prefix length.\n+\n+These yield identical results::\n+\n+ ipv4 src is 10.1.1.1\n+\n+::\n+\n+ ipv4 src spec 10.1.1.1 src mask 255.255.255.255\n+\n+::\n+\n+ ipv4 src spec 10.1.1.1 src prefix 32\n+\n+::\n+\n+ ipv4 src is 10.1.1.1 src last 10.1.1.1 # range with a single value\n+\n+::\n+\n+ ipv4 src is 10.1.1.1 src last 0 # 0 disables range\n+\n+Inclusive ranges can be defined with ``last``::\n+\n+ ipv4 src is 10.1.1.1 src last 10.2.3.4 # 10.1.1.1 to 10.2.3.4\n+\n+Note that ``mask`` affects both ``spec`` and ``last``::\n+\n+ ipv4 src is 10.1.1.1 src last 10.2.3.4 src mask 255.255.0.0\n+ # matches 10.1.0.0 to 10.2.255.255\n+\n+Properties can be modified multiple times::\n+\n+ ipv4 src is 10.1.1.1 src is 10.1.2.3 src is 10.2.3.4 # matches 10.2.3.4\n+\n+::\n+\n+ ipv4 src is 10.1.1.1 src prefix 24 src prefix 16 # matches 10.1.0.0/16\n+\n+Pattern items\n+^^^^^^^^^^^^^\n+\n+This section lists supported pattern items and their attributes, if any.\n+\n+- ``end``: end list of pattern items.\n+\n+- ``void``: no-op pattern item.\n+\n+- ``invert``: perform actions when pattern does not match.\n+\n+- ``any``: match any protocol for the current layer.\n+\n+ - ``num {unsigned}``: number of layers covered.\n+\n+- ``pf``: match packets addressed to the physical function.\n+\n+- ``vf``: match packets addressed to a virtual function ID.\n+\n+ - ``id {unsigned}``: destination VF ID.\n+\n+- ``port``: device-specific physical port index to use.\n+\n+ - ``index {unsigned}``: physical port index.\n+\n+- ``raw``: match an arbitrary byte string.\n+\n+ - ``relative {boolean}``: look for pattern after the previous item.\n+ - ``search {boolean}``: search pattern from offset (see also limit).\n+ - ``offset {integer}``: absolute or relative offset for pattern.\n+ - ``limit {unsigned}``: search area limit for start of pattern.\n+ - ``pattern {string}``: byte string to look for.\n+\n+- ``eth``: match Ethernet header.\n+\n+ - ``dst {MAC-48}``: destination MAC.\n+ - ``src {MAC-48}``: source MAC.\n+ - ``type {unsigned}``: EtherType.\n+\n+- ``vlan``: match 802.1Q/ad VLAN tag.\n+\n+ - ``tpid {unsigned}``: tag protocol identifier.\n+ - ``tci {unsigned}``: tag control information.\n+\n+- ``ipv4``: match IPv4 header.\n+\n+ - ``src {ipv4 address}``: source address.\n+ - ``dst {ipv4 address}``: destination address.\n+\n+- ``ipv6``: match IPv6 header.\n+\n+ - ``src {ipv6 address}``: source address.\n+ - ``dst {ipv6 address}``: destination address.\n+\n+- ``icmp``: match ICMP header.\n+\n+ - ``type {unsigned}``: ICMP packet type.\n+ - ``code {unsigned}``: ICMP packet code.\n+\n+- ``udp``: match UDP header.\n+\n+ - ``src {unsigned}``: UDP source port.\n+ - ``dst {unsigned}``: UDP destination port.\n+\n+- ``tcp``: match TCP header.\n+\n+ - ``src {unsigned}``: TCP source port.\n+ - ``dst {unsigned}``: TCP destination port.\n+\n+- ``sctp``: match SCTP header.\n+\n+ - ``src {unsigned}``: SCTP source port.\n+ - ``dst {unsigned}``: SCTP destination port.\n+\n+- ``vxlan``: match VXLAN header.\n+\n+ - ``vni {unsigned}``: VXLAN identifier.\n+\n+Actions list\n+^^^^^^^^^^^^\n+\n+A list of actions starts after the ``actions`` token in the same fashion as\n+`Matching pattern`_; actions are separated by ``/`` tokens and the list is\n+terminated by a mandatory ``end`` action.\n+\n+Actions are named after their type (*RTE_FLOW_ACTION_TYPE_* from ``enum\n+rte_flow_action_type``).\n+\n+Dropping all incoming UDPv4 packets can be expressed as follows::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end\n+ actions drop / end\n+\n+Several actions have configurable properties which must be specified when\n+there is no valid default value. For example, ``queue`` requires a target\n+queue index.\n+\n+This rule redirects incoming UDPv4 traffic to queue index 6::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end\n+ actions queue index 6 / end\n+\n+While this one could be rejected by PMDs (unspecified queue index)::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end\n+ actions queue / end\n+\n+As defined by *rte_flow*, the list is not ordered, all actions of a given\n+rule are performed simultaneously. These are equivalent::\n+\n+ queue index 6 / void / mark id 42 / end\n+\n+::\n+\n+ void / mark id 42 / queue index 6 / end\n+\n+All actions in a list should have different types, otherwise only the last\n+action of a given type is taken into account::\n+\n+ queue index 4 / queue index 5 / queue index 6 / end # will use queue 6\n+\n+::\n+\n+ drop / drop / drop / end # drop is performed only once\n+\n+::\n+\n+ mark id 42 / queue index 3 / mark id 24 / end # mark will be 24\n+\n+Considering they are performed simultaneously, opposite and overlapping\n+actions can sometimes be combined when the end result is unambiguous::\n+\n+ drop / queue index 6 / end # drop has no effect\n+\n+::\n+\n+ drop / dup index 6 / end # same as above\n+\n+::\n+\n+ queue index 6 / rss queues 6 7 8 / end # queue has no effect\n+\n+::\n+\n+ drop / passthru / end # drop has no effect\n+\n+Note that PMDs may still refuse such combinations.\n+\n+Actions\n+^^^^^^^\n+\n+This section lists supported actions and their attributes, if any.\n+\n+- ``end``: end list of actions.\n+\n+- ``void``: no-op action.\n+\n+- ``passthru``: let subsequent rule process matched packets.\n+\n+- ``mark``: attach 32 bit value to packets.\n+\n+ - ``id {unsigned}``: 32 bit value to return with packets.\n+\n+- ``flag``: flag packets.\n+\n+- ``queue``: assign packets to a given queue index.\n+\n+ - ``index {unsigned}``: queue index to use.\n+\n+- ``drop``: drop packets (note: passthru has priority).\n+\n+- ``count``: enable counters for this rule.\n+\n+- ``dup``: duplicate packets to a given queue index.\n+\n+ - ``index {unsigned}``: queue index to duplicate packets to.\n+\n+- ``rss``: spread packets among several queues.\n+\n+ - ``queues [{unsigned} [...]] end``: queue indices to use.\n+\n+- ``pf``: redirect packets to physical device function.\n+\n+- ``vf``: redirect packets to virtual device function.\n+\n+ - ``original {boolean}``: use original VF ID if possible.\n+ - ``id {unsigned}``: VF ID to redirect packets to.\n+\n+Destroying flow rules\n+~~~~~~~~~~~~~~~~~~~~~\n+\n+``flow destroy`` destroys one or more rules from their rule ID (as returned\n+by ``flow create``), this command calls ``rte_flow_destroy()`` as many\n+times as necessary::\n+\n+ flow destroy {port_id} rule {rule_id} [...]\n+\n+If successful, it will show::\n+\n+ Flow rule #[...] destroyed\n+\n+It does not report anything for rule IDs that do not exist. The usual error\n+message is shown when a rule cannot be destroyed::\n+\n+ Caught error type [...] ([...]): [...]\n+\n+``flow flush`` destroys all rules on a device and does not take extra\n+arguments. It is bound to ``rte_flow_flush()``::\n+\n+ flow flush {port_id}\n+\n+Any errors are reported as above.\n+\n+Creating several rules and destroying them::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv6 / end\n+ actions queue index 2 / end\n+ Flow rule #0 created\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / end\n+ actions queue index 3 / end\n+ Flow rule #1 created\n+ testpmd> flow destroy 0 rule 0 rule 1\n+ Flow rule #1 destroyed\n+ Flow rule #0 destroyed\n+ testpmd>\n+\n+The same result can be achieved using ``flow flush``::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv6 / end\n+ actions queue index 2 / end\n+ Flow rule #0 created\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / end\n+ actions queue index 3 / end\n+ Flow rule #1 created\n+ testpmd> flow flush 0\n+ testpmd>\n+\n+Non-existent rule IDs are ignored::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv6 / end\n+ actions queue index 2 / end\n+ Flow rule #0 created\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / end\n+ actions queue index 3 / end\n+ Flow rule #1 created\n+ testpmd> flow destroy 0 rule 42 rule 10 rule 2\n+ testpmd>\n+ testpmd> flow destroy 0 rule 0\n+ Flow rule #0 destroyed\n+ testpmd>\n+\n+Querying flow rules\n+~~~~~~~~~~~~~~~~~~~\n+\n+``flow query`` queries a specific action of a flow rule having that\n+ability. Such actions collect information that can be reported using this\n+command. It is bound to ``rte_flow_query()``::\n+\n+ flow query {port_id} {rule_id} {action}\n+\n+If successful, it will display either the retrieved data for known actions\n+or the following message::\n+\n+ Cannot display result for action type [...] ([...])\n+\n+Otherwise, it will complain either that the rule does not exist or that some\n+error occurred::\n+\n+ Flow rule #[...] not found\n+\n+::\n+\n+ Caught error type [...] ([...]): [...]\n+\n+Currently only the ``count`` action is supported. This action reports the\n+number of packets that hit the flow rule and the total number of bytes. Its\n+output has the following format::\n+\n+ count:\n+ hits_set: [...] # whether \"hits\" contains a valid value\n+ bytes_set: [...] # whether \"bytes\" contains a valid value\n+ hits: [...] # number of packets\n+ bytes: [...] # number of bytes\n+\n+Querying counters for TCPv6 packets redirected to queue 6::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv6 / tcp / end\n+ actions queue index 6 / count / end\n+ Flow rule #4 created\n+ testpmd> flow query 0 4 count\n+ count:\n+ hits_set: 1\n+ bytes_set: 0\n+ hits: 386446\n+ bytes: 0\n+ testpmd>\n+\n+Listing flow rules\n+~~~~~~~~~~~~~~~~~~\n+\n+``flow list`` lists existing flow rules sorted by priority and optionally\n+filtered by group identifiers::\n+\n+ flow list {port_id} [group {group_id}] [...]\n+\n+This command only fails with the following message if the device does not\n+exist::\n+\n+ Invalid port [...]\n+\n+Output consists of a header line followed by a short description of each\n+flow rule, one per line. There is no output at all when no flow rules are\n+configured on the device::\n+\n+ ID Group Prio Attr Rule\n+ [...] [...] [...] [...] [...]\n+\n+``Attr`` column flags:\n+\n+- ``i`` for ``ingress``.\n+- ``e`` for ``egress``.\n+\n+Creating several flow rules and listing them::\n+\n+ testpmd> flow create 0 ingress pattern eth / ipv4 / end\n+ actions queue index 6 / end\n+ Flow rule #0 created\n+ testpmd> flow create 0 ingress pattern eth / ipv6 / end\n+ actions queue index 2 / end\n+ Flow rule #1 created\n+ testpmd> flow create 0 priority 5 ingress pattern eth / ipv4 / udp / end\n+ actions rss queues 6 7 8 end / end\n+ Flow rule #2 created\n+ testpmd> flow list 0\n+ ID Group Prio Attr Rule\n+ 0 0 0 i- ETH IPV4 => QUEUE\n+ 1 0 0 i- ETH IPV6 => QUEUE\n+ 2 0 5 i- ETH IPV4 UDP => RSS\n+ testpmd>\n+\n+Rules are sorted by priority (i.e. group ID first, then priority level)::\n+\n+ testpmd> flow list 1\n+ ID Group Prio Attr Rule\n+ 0 0 0 i- ETH => COUNT\n+ 6 0 500 i- ETH IPV6 TCP => DROP COUNT\n+ 5 0 1000 i- ETH IPV6 ICMP => QUEUE\n+ 1 24 0 i- ETH IPV4 UDP => QUEUE\n+ 4 24 10 i- ETH IPV4 TCP => DROP\n+ 3 24 20 i- ETH IPV4 => DROP\n+ 2 24 42 i- ETH IPV4 UDP => QUEUE\n+ 7 63 0 i- ETH IPV6 UDP VXLAN => MARK QUEUE\n+ testpmd>\n+\n+Output can be limited to specific groups::\n+\n+ testpmd> flow list 1 group 0 group 63\n+ ID Group Prio Attr Rule\n+ 0 0 0 i- ETH => COUNT\n+ 6 0 500 i- ETH IPV6 TCP => DROP COUNT\n+ 5 0 1000 i- ETH IPV6 ICMP => QUEUE\n+ 7 63 0 i- ETH IPV6 UDP VXLAN => MARK QUEUE\n+ testpmd>\n", "prefixes": [ "dpdk-dev", "v3", "25/25" ] }