Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/101429/?format=api
{ "id": 101429, "url": "http://patches.dpdk.org/api/patches/101429/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/patch/20211013170233.25876-7-ivan.malov@oktetlabs.ru/", "project": { "id": 1, "url": "http://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": "<20211013170233.25876-7-ivan.malov@oktetlabs.ru>", "list_archive_url": "https://inbox.dpdk.org/dev/20211013170233.25876-7-ivan.malov@oktetlabs.ru", "date": "2021-10-13T17:02:27", "name": "[v6,06/12] ethdev: deprecate direction attributes in transfer flows", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": true, "hash": "9375211f25dbd1c521a91e37a641c02f80a9d65b", "submitter": { "id": 869, "url": "http://patches.dpdk.org/api/people/869/?format=api", "name": "Ivan Malov", "email": "Ivan.Malov@oktetlabs.ru" }, "delegate": { "id": 319, "url": "http://patches.dpdk.org/api/users/319/?format=api", "username": "fyigit", "first_name": "Ferruh", "last_name": "Yigit", "email": "ferruh.yigit@amd.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/patch/20211013170233.25876-7-ivan.malov@oktetlabs.ru/mbox/", "series": [ { "id": 19608, "url": "http://patches.dpdk.org/api/series/19608/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=19608", "date": "2021-10-13T17:02:21", "name": "ethdev: rework transfer flow API", "version": 6, "mbox": "http://patches.dpdk.org/series/19608/mbox/" } ], "comments": "http://patches.dpdk.org/api/patches/101429/comments/", "check": "success", "checks": "http://patches.dpdk.org/api/patches/101429/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from mails.dpdk.org (mails.dpdk.org [217.70.189.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id AF11DA0C47;\n\tWed, 13 Oct 2021 19:03:30 +0200 (CEST)", "from [217.70.189.124] (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id 8CCF04118B;\n\tWed, 13 Oct 2021 19:03:03 +0200 (CEST)", "from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])\n by mails.dpdk.org (Postfix) with ESMTP id 84B014067C\n for <dev@dpdk.org>; Wed, 13 Oct 2021 19:02:50 +0200 (CEST)", "from localhost.localdomain (unknown [5.144.123.99])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 2B9317F6FA;\n Wed, 13 Oct 2021 20:02:50 +0300 (MSK)" ], "DKIM-Filter": "OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2B9317F6FA", "DKIM-Signature": "v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;\n s=default; t=1634144570;\n bh=g9fVePOWOYXDiJmAwzt611bNO3nkHSrzHEW3QBzDPvo=;\n h=From:To:Cc:Subject:Date:In-Reply-To:References;\n b=m7TvpUtjYgNeeCBh26IT2XTTDLJp1JWeo4FyktfvAd6KPSlSKdYMcCJoHd4vjcz4L\n /LBtidNv6iFgkEw7W57bcECgj5+zLAROYUMs6z/0+0l6DxBxxTY09RXZEWERNyUyZe\n ZTpY+w+qtLoCndSvC/IFzM3wEVU0ZCEqtNkP/q1Q=", "From": "Ivan Malov <ivan.malov@oktetlabs.ru>", "To": "dev@dpdk.org", "Cc": "Ferruh Yigit <ferruh.yigit@intel.com>,\n Thomas Monjalon <thomas@monjalon.net>, Ori Kam <orika@nvidia.com>,\n Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,\n Ray Kinsella <mdr@ashroe.eu>", "Date": "Wed, 13 Oct 2021 20:02:27 +0300", "Message-Id": "<20211013170233.25876-7-ivan.malov@oktetlabs.ru>", "X-Mailer": "git-send-email 2.20.1", "In-Reply-To": "<20211013170233.25876-1-ivan.malov@oktetlabs.ru>", "References": "<20211001134716.1608857-1-andrew.rybchenko@oktetlabs.ru>\n <20211013170233.25876-1-ivan.malov@oktetlabs.ru>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "Subject": "[dpdk-dev] [PATCH v6 06/12] ethdev: deprecate direction attributes\n in transfer flows", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "Attributes \"ingress\" and \"egress\" can only apply unambiguosly\nto non-\"transfer\" flows. In \"transfer\" flows, the standpoint\nis effectively shifted to the embedded switch. There can be\nmany different endpoints connected to the switch, so the\nuse of \"ingress\" / \"egress\" does not shed light on which\nendpoints precisely can be considered as traffic sources.\n\nAdd relevant deprecation notices and suggest the use of precise\ntraffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).\n\nSigned-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>\nAcked-by: Ori Kam <orika@nvidia.com>\nAcked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>\n---\n doc/guides/prog_guide/rte_flow.rst | 28 ++++++++----------\n doc/guides/rel_notes/deprecation.rst | 9 +++---\n doc/guides/rel_notes/release_21_11.rst | 3 ++\n lib/ethdev/rte_flow.h | 41 ++++++++++++++++++++------\n 4 files changed, 52 insertions(+), 29 deletions(-)", "diff": "diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst\nindex d7185c49df..5957b8df4f 100644\n--- a/doc/guides/prog_guide/rte_flow.rst\n+++ b/doc/guides/prog_guide/rte_flow.rst\n@@ -9,8 +9,8 @@ Overview\n --------\n \n This API provides a generic means to configure hardware to match specific\n-ingress or egress traffic, alter its fate and query related counters\n-according to any number of user-defined rules.\n+traffic, alter its fate and query related counters according to any\n+number of user-defined rules.\n \n It is named *rte_flow* after the prefix used for all its symbols, and is\n defined in ``rte_flow.h``.\n@@ -146,13 +146,10 @@ Note that support for more than a single priority level is not guaranteed.\n Attribute: Traffic direction\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n \n-Flow rule patterns apply to inbound and/or outbound traffic.\n-\n-In the context of this API, **ingress** and **egress** respectively stand\n-for **inbound** and **outbound** based on the standpoint of the application\n-creating a flow rule.\n-\n-There are no exceptions to this definition.\n+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply\n+to inbound and / or outbound traffic. With this respect, ``ingress``\n+and ``egress`` respectively stand for **inbound** and **outbound**\n+based on the standpoint of the application creating a flow rule.\n \n Several pattern items and actions are valid and can be used in both\n directions. At least one direction must be specified.\n@@ -171,12 +168,13 @@ When supported, this effectively enables an application to reroute traffic\n not necessarily intended for it (e.g. coming from or addressed to different\n physical ports, VFs or applications) at the device level.\n \n-It complements the behavior of some pattern items such as `Item: PHY_PORT`_\n-and is meaningless without them.\n-\n-When transferring flow rules, **ingress** and **egress** attributes\n-(`Attribute: Traffic direction`_) keep their original meaning, as if\n-processing traffic emitted or received by the application.\n+In \"transfer\" flows, the use of `Attribute: Traffic direction`_ in the sense of\n+implicitly matching packets going to or going from the ethdev used to create\n+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to\n+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as\n+the switch serves many different endpoints. The application should match\n+traffic originating from precise locations. To do so, it should\n+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.\n \n Pattern item\n ~~~~~~~~~~~~\ndiff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst\nindex 25aec56bec..ef2e2c1141 100644\n--- a/doc/guides/rel_notes/deprecation.rst\n+++ b/doc/guides/rel_notes/deprecation.rst\n@@ -113,11 +113,6 @@ Deprecation Notices\n to support modifying fields larger than 64 bits.\n In addition, documentation will be updated to clarify byte order.\n \n-* ethdev: Flow API documentation is unclear if ethdev port used to create\n- a flow rule adds any implicit match criteria in the case of transfer rules.\n- The semantics will be clarified in DPDK 21.11 and it will require fixes in\n- drivers and applications which interpret it in a different way.\n-\n * ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,\n should start with relevant protocol header.\n Some matching pattern structures implements this by duplicating protocol header\n@@ -146,6 +141,10 @@ Deprecation Notices\n * ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are\n deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.\n \n+* ethdev: The use of attributes ``ingress`` / ``egress`` in \"transfer\" flows\n+ is deprecated as ambiguous with respect to the embedded switch. The use of\n+ these attributes will become invalid starting from DPDK 22.11.\n+\n * net: The structure ``rte_ipv4_hdr`` will have two unions.\n The first union is for existing ``version_ihl`` byte\n and new bitfield for version and IHL.\ndiff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst\nindex 75c4f6d018..45c019eb04 100644\n--- a/doc/guides/rel_notes/release_21_11.rst\n+++ b/doc/guides/rel_notes/release_21_11.rst\n@@ -257,6 +257,9 @@ API Changes\n * ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.\n Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.\n \n+* ethdev: Deprecated the use of attributes ``ingress`` / ``egress`` combined\n+ with ``transfer``. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.\n+\n \n ABI Changes\n -----------\ndiff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h\nindex 76653105a0..7e7b4bce5b 100644\n--- a/lib/ethdev/rte_flow.h\n+++ b/lib/ethdev/rte_flow.h\n@@ -67,7 +67,10 @@ extern \"C\" {\n * Note that support for more than a single group and priority level is not\n * guaranteed.\n *\n- * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).\n+ * At vNIC / ethdev level, flow rules can apply to inbound and / or outbound\n+ * traffic (ingress / egress), with respect to the vNIC / ethdev in question.\n+ * At embedded switch level, flow rules apply to all traffic seen by it\n+ * unless fitting meta items are used to set concrete traffic source(s).\n *\n * Several pattern items and actions are valid and can be used in both\n * directions. Those valid for only one direction are described as such.\n@@ -80,8 +83,32 @@ extern \"C\" {\n struct rte_flow_attr {\n \tuint32_t group; /**< Priority group. */\n \tuint32_t priority; /**< Rule priority level within group. */\n-\tuint32_t ingress:1; /**< Rule applies to ingress traffic. */\n-\tuint32_t egress:1; /**< Rule applies to egress traffic. */\n+\t/**\n+\t * The rule in question applies to ingress traffic (non-\"transfer\").\n+\t *\n+\t * @deprecated\n+\t * It has been possible to combine this attribute with \"transfer\".\n+\t * Doing so has been assumed to restrict the scope of matching\n+\t * to traffic going from within the embedded switch toward the\n+\t * ethdev the flow rule being created through. This behaviour\n+\t * is deprecated. During the transition period, one may still\n+\t * rely on it, but PMDs and applications are encouraged to\n+\t * gradually move away from this approach.\n+\t */\n+\tuint32_t ingress:1;\n+\t/**\n+\t * The rule in question applies to egress traffic (non-\"transfer\").\n+\t *\n+\t * @deprecated\n+\t * It has been possible to combine this attribute with \"transfer\".\n+\t * Doing so has been assumed to restrict the scope of matching\n+\t * to traffic sent by the application by virtue of the ethdev\n+\t * the flow rule being created through. This behaviour is now\n+\t * deprecated. During the transition period, one may still\n+\t * rely on it, but PMDs and applications are encouraged to\n+\t * gradually move away from this approach.\n+\t */\n+\tuint32_t egress:1;\n \t/**\n \t * Instead of simply matching the properties of traffic as it would\n \t * appear on a given DPDK port ID, enabling this attribute transfers\n@@ -93,12 +120,8 @@ struct rte_flow_attr {\n \t * from or addressed to different physical ports, VFs or\n \t * applications) at the device level.\n \t *\n-\t * It complements the behavior of some pattern items such as\n-\t * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them.\n-\t *\n-\t * When transferring flow rules, ingress and egress attributes keep\n-\t * their original meaning, as if processing traffic emitted or\n-\t * received by the application.\n+\t * The application should match traffic originating from precise\n+\t * locations. See items PORT_REPRESENTOR and REPRESENTED_PORT.\n \t */\n \tuint32_t transfer:1;\n \tuint32_t reserved:29; /**< Reserved, must be zero. */\n", "prefixes": [ "v6", "06/12" ] }