From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by dpdk.org (Postfix) with ESMTP id D1DDE1BAD1 for ; Tue, 10 Apr 2018 18:36:55 +0200 (CEST) Received: by mail-wr0-f194.google.com with SMTP id u11so13447176wri.12 for ; Tue, 10 Apr 2018 09:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hpGIhLAzVvNRUkA0d0aWxe+o4mhLBK0k3ndMWLatO5U=; b=Cq44Bi/AosH42u8FjC3ssKgoxe7PAkGaSpHeTAHJEyiHiIuH3vSuiZOYJbO7+disCc 6e8pgXFyECDX88t/sIPEcipxxK97zwFvR98KzmVROOLl8ruXBAO8JWJZqMljg6KlOiTX 8lsayaDPc2pNvpX2pDf6h6JX3HlGsuJdOcBcHluRuevpSSrf+sS8kyFQ2TpHyty5umH8 BrPCAk+AP4XnQmxVB0FGOKu1u+1+iA+5nREcZfZIkb3PujvYHVsLXenyoDh3JOkHjstf IP6p9yu9duf+7MC15cVuXAPL6Wa9xq0p33IIthv+km2t+RRZynYJ3ksWe8AIV8Lc1XwP ouOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hpGIhLAzVvNRUkA0d0aWxe+o4mhLBK0k3ndMWLatO5U=; b=kS+igySwHWjHlB5Mrhci6E3YA/FmO/3ueEHyXoobkpvJOvJwzC8E7AGIZS8nQp54Yq qjOAZIzik9UweOWWeMfyLGNXFWYr/kzxp/FoCwH3rMgPc4xUtjuOLPoigSvYu+UED6Hj wI6ytrwIZnnkavZ6zTH3QWbr7mufNdcFCd0LJ+avs2HNx+dLkwbLwBS+msBbevRMJgPR cITUSuIukMvHcuivxu+O1IoO2vLPrFbaRo7yk2w5H5cac4IyApT4KqOkpyaQdwFMm8CV tQ8jPa6Y8r2URdqypHsbvY9WL3w93ZecZVEA4Y5QYfZLu4P5cZ65aFrIyTIFGQzNOXgs 6+8g== X-Gm-Message-State: ALQs6tDGiMz3h21rNiCPNNs+gUZsiCBOiQm8h6dtm98rTRfaLFFpTvUe 9GM4mcbD/KuHj66QeP49OiUaAQ== X-Google-Smtp-Source: AIpwx48GuNuMx+f3J+mkyb4G8JwA82xYH7ODDSniivb3scu2kPmxhuuIaB+0DB/gZFD17jWfXNX9/Q== X-Received: by 10.223.152.80 with SMTP id v74mr831289wrb.163.1523378215596; Tue, 10 Apr 2018 09:36:55 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id t196sm1903319wme.35.2018.04.10.09.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 09:36:55 -0700 (PDT) Date: Tue, 10 Apr 2018 18:36:41 +0200 From: Adrien Mazarguil To: Thomas Monjalon , Ferruh Yigit , dev@dpdk.org Message-ID: <20180410162022.9101-3-adrien.mazarguil@6wind.com> References: <20180406131736.19145-1-adrien.mazarguil@6wind.com> <20180410162022.9101-1-adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410162022.9101-1-adrien.mazarguil@6wind.com> X-Mailer: git-send-email 2.11.0 Subject: [dpdk-dev] [PATCH v3 02/16] ethdev: clarify flow API pattern items and actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 16:36:56 -0000 Although pattern items and actions examples end with "and so on", these lists include all existing definitions and as a result are updated almost every time new types are added. This is cumbersome and pointless. This patch also synchronizes Doxygen and external API documentation wording with a slight clarification regarding meta pattern items. No fundamental API change. Signed-off-by: Adrien Mazarguil Acked-by: Andrew Rybchenko --- doc/guides/prog_guide/rte_flow.rst | 23 +++++++++++------------ lib/librte_ether/rte_flow.h | 23 ++++++++++------------- 2 files changed, 21 insertions(+), 25 deletions(-) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 961943dda..a11ebd617 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -186,12 +186,13 @@ Pattern item Pattern items fall in two categories: -- Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4, - IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE, ESP and so on), usually - associated with a specification structure. +- Matching protocol headers and packet data, usually associated with a + specification structure. These must be stacked in the same order as the + protocol layers to match inside packets, starting from the lowest. -- Matching meta-data or affecting pattern processing (END, VOID, INVERT, PF, - VF, PORT and so on), often without a specification structure. +- Matching meta-data or affecting pattern processing, often without a + specification structure. Since they do not match packet contents, their + position in the list is usually not relevant. Item specification structures are used to match specific values among protocol fields (or item properties). Documentation describes for each item @@ -1001,15 +1002,13 @@ to a flow rule. That list is not ordered. They fall in three categories: -- Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent - processing matched packets by subsequent flow rules, unless overridden - with PASSTHRU. +- Terminating actions that prevent processing matched packets by subsequent + flow rules, unless overridden with PASSTHRU. -- Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for - additional processing by subsequent flow rules. +- Non-terminating actions that leave matched packets up for additional + processing by subsequent flow rules. -- Other non-terminating meta actions that do not affect the fate of packets - (END, VOID, MARK, FLAG, COUNT, SECURITY). +- Other non-terminating meta actions that do not affect the fate of packets. When several actions are combined in a flow rule, they should all have different types (e.g. dropping a packet twice is not possible). diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h index 95799fd9c..36fd38ffa 100644 --- a/lib/librte_ether/rte_flow.h +++ b/lib/librte_ether/rte_flow.h @@ -78,15 +78,13 @@ struct rte_flow_attr { * * Pattern items fall in two categories: * - * - Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4, - * IPV6, ICMP, UDP, TCP, SCTP, VXLAN and so on), usually associated with a + * - Matching protocol headers and packet data, usually associated with a * specification structure. These must be stacked in the same order as the - * protocol layers to match, starting from the lowest. + * protocol layers to match inside packets, starting from the lowest. * - * - Matching meta-data or affecting pattern processing (END, VOID, INVERT, - * PF, VF, PORT and so on), often without a specification structure. Since - * they do not match packet contents, these can be specified anywhere - * within item lists without affecting others. + * - Matching meta-data or affecting pattern processing, often without a + * specification structure. Since they do not match packet contents, their + * position in the list is usually not relevant. * * See the description of individual types for more information. Those * marked with [META] fall into the second category. @@ -865,15 +863,14 @@ struct rte_flow_item { * * They fall in three categories: * - * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent - * processing matched packets by subsequent flow rules, unless overridden - * with PASSTHRU. + * - Terminating actions that prevent processing matched packets by + * subsequent flow rules, unless overridden with PASSTHRU. * - * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up - * for additional processing by subsequent flow rules. + * - Non terminating actions that leave matched packets up for additional + * processing by subsequent flow rules. * * - Other non terminating meta actions that do not affect the fate of - * packets (END, VOID, MARK, FLAG, COUNT). + * packets. * * When several actions are combined in a flow rule, they should all have * different types (e.g. dropping a packet twice is not possible). -- 2.11.0