DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bing Zhao <bingz@nvidia.com>
To: <orika@nvidia.com>, <aman.deep.singh@intel.com>,
	<yuying.zhang@intel.com>,  <dsosnowski@nvidia.com>,
	<viacheslavo@nvidia.com>, <suanmingm@nvidia.com>,
	 <matan@nvidia.com>, <thomas@monjalon.net>,
	<ferruh.yigit@amd.com>, <andrew.rybchenko@oktetlabs.ru>,
	<dev@dpdk.org>, <rasland@nvidia.com>
Subject: [PATCH v2 1/2] ethdev: introduce NAT64 action
Date: Wed, 31 Jan 2024 11:38:03 +0200	[thread overview]
Message-ID: <20240131093804.357465-2-bingz@nvidia.com> (raw)
In-Reply-To: <20240131093804.357465-1-bingz@nvidia.com>

In order to support the communication between IPv4 and IPv6 nodes in
the network, different technologies are used, like dual-stacks,
tunneling and NAT64. In some IPv4-only clients, it is hard to deploy
new software and(or) hardware to support IPv6 protocol.

NAT64 is a choice and it will also reduce the unnecessary overhead of
the traffic in the network. The NAT64 gateways take the
responsibility of the packet headers translation between the IPv6
clouds and IPv4-only clouds.

The commit introduce the NAT64 flow action to offload the software
involvement to the hardware.

This action should support the offloading of the IP headers'
translation. The following fields should be reset correctly in the
translation.
  - Version
  - Traffic Class / TOS
  - Flow Label (0 in v4)
  - Payload Length / Total length
  - Next Header
  - Hop Limit / TTL

The PMD needs to support the basic conversion of the fields above,
and the well-known prefix will be used when translating IPv4 address
to IPv6 address. Another modify fields can be used after the NAT64 to
support other modes with different prefix and offset.

The ICMP* and transport layers protocol is out of the scope of NAT64
rte_flow action.

Reference links:
  - https://datatracker.ietf.org/doc/html/rfc6146
  - https://datatracker.ietf.org/doc/html/rfc6052
  - https://datatracker.ietf.org/doc/html/rfc6145

Signed-off-by: Bing Zhao <bingz@nvidia.com>
---
 doc/guides/nics/features/default.ini |  1 +
 doc/guides/prog_guide/rte_flow.rst   |  8 ++++++++
 lib/ethdev/rte_flow.c                |  1 +
 lib/ethdev/rte_flow.h                | 27 +++++++++++++++++++++++++++
 4 files changed, 37 insertions(+)

diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 6d50236292..4db7e41193 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -171,6 +171,7 @@ mark                 =
 meter                =
 meter_mark           =
 modify_field         =
+nat64                =
 nvgre_decap          =
 nvgre_encap          =
 of_copy_ttl_in       =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 900fdaefb6..7af329bd93 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3520,6 +3520,14 @@ The packets will be received by the kernel driver sharing the same device
 as the DPDK port on which this action is configured.
 
 
+Action: ``NAT64``
+^^^^^^^^^^^^^^^^^
+
+This action does the header translation between IPv4 and IPv6. Besides
+converting the IP addresses, other fields in the IP header are handled as
+well. The ``type`` field should be provided as defined in the
+``rte_flow_action_nat64`` when creating the action.
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 3f58d792f9..156545454c 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -271,6 +271,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
 		       sizeof(struct rte_flow_action_indirect_list)),
 	MK_FLOW_ACTION(PROG,
 		       sizeof(struct rte_flow_action_prog)),
+	MK_FLOW_ACTION(NAT64, sizeof(struct rte_flow_action_nat64)),
 };
 
 int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 1267c146e5..1dded812ec 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3051,6 +3051,13 @@ enum rte_flow_action_type {
 	 * @see struct rte_flow_action_prog.
 	 */
 	RTE_FLOW_ACTION_TYPE_PROG,
+
+	/**
+	 * Support the NAT64 translation.
+	 *
+	 * @see struct rte_flow_action_nat64
+	 */
+	RTE_FLOW_ACTION_TYPE_NAT64,
 };
 
 /**
@@ -4180,6 +4187,26 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v)
 	*RTE_FLOW_DYNF_METADATA(m) = v;
 }
 
+/**
+ * NAT64 translation type for IP headers.
+ */
+enum rte_flow_nat64_type {
+	RTE_FLOW_NAT64_6TO4 = 0, /**< IPv6 to IPv4 headers translation. */
+	RTE_FLOW_NAT64_4TO6 = 1, /**< IPv4 to IPv6 headers translation. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_NAT64
+ *
+ * Specify the NAT64 translation type.
+ */
+struct rte_flow_action_nat64 {
+	enum rte_flow_nat64_type type;
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.34.1


  reply	other threads:[~2024-01-31  9:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-27  9:07 [PATCH 0/8] support " Bing Zhao
2023-12-27  9:07 ` [PATCH 1/8] ethdev: introduce " Bing Zhao
2023-12-27  9:07 ` [PATCH 2/8] app/testpmd: add support for NAT64 in the command line Bing Zhao
2023-12-27  9:07 ` [PATCH 3/8] net/mlx5: fetch the available registers for NAT64 Bing Zhao
2023-12-27  9:07 ` [PATCH 4/8] common/mlx5: add new modify field defininations Bing Zhao
2023-12-27  9:07 ` [PATCH 5/8] net/mlx5/hws: support NAT64 action Bing Zhao
2023-12-27  9:07 ` [PATCH 6/8] net/mlx5: create NAT64 actions during configuration Bing Zhao
2023-12-27  9:07 ` [PATCH 7/8] net/mlx5: add NAT64 action support in rule creation Bing Zhao
2023-12-27  9:07 ` [PATCH 8/8] net/mlx5: validate the actions combination with NAT64 Bing Zhao
2024-01-31  9:38 ` [PATCH v2 0/2] support NAT64 action Bing Zhao
2024-01-31  9:38   ` Bing Zhao [this message]
2024-02-01  8:38     ` [PATCH v2 1/2] ethdev: introduce " Ori Kam
2024-01-31  9:38   ` [PATCH v2 2/2] app/testpmd: add support for NAT64 in the command line Bing Zhao
2024-02-01  8:38     ` Ori Kam
2024-02-01 16:00   ` [PATCH v2 0/2] support NAT64 action Ferruh Yigit
2024-02-01 16:05     ` Ferruh Yigit
2024-02-20 14:10 ` [PATCH v2 0/5] NAT64 support in mlx5 PMD Bing Zhao
2024-02-20 14:10   ` [PATCH v2 1/5] net/mlx5/hws: support NAT64 action Bing Zhao
2024-02-20 14:10   ` [PATCH v2 2/5] net/mlx5: fetch the available registers for NAT64 Bing Zhao
2024-02-20 14:10   ` [PATCH v2 3/5] net/mlx5: create NAT64 actions during configuration Bing Zhao
2024-02-20 14:10   ` [PATCH v2 4/5] net/mlx5: add NAT64 action support in rule creation Bing Zhao
2024-02-20 14:10   ` [PATCH v2 5/5] net/mlx5: validate the actions combination with NAT64 Bing Zhao
2024-02-20 14:37 ` [PATCH v3 0/5] NAT64 support in mlx5 PMD Bing Zhao
2024-02-20 14:37   ` [PATCH v3 1/5] net/mlx5/hws: support NAT64 action Bing Zhao
2024-02-20 14:37   ` [PATCH v3 2/5] net/mlx5: fetch the available registers for NAT64 Bing Zhao
2024-02-20 14:37   ` [PATCH v3 3/5] net/mlx5: create NAT64 actions during configuration Bing Zhao
2024-02-20 14:37   ` [PATCH v3 4/5] net/mlx5: add NAT64 action support in rule creation Bing Zhao
2024-02-20 14:37   ` [PATCH v3 5/5] net/mlx5: validate the actions combination with NAT64 Bing Zhao
2024-02-21 13:14   ` [PATCH v3 0/5] NAT64 support in mlx5 PMD Ori Kam
2024-02-28 15:09 ` [PATCH v4 " Bing Zhao
2024-02-28 15:09   ` [PATCH v4 1/5] net/mlx5/hws: support NAT64 action Bing Zhao
2024-02-28 15:09   ` [PATCH v4 2/5] net/mlx5: fetch the available registers for NAT64 Bing Zhao
2024-02-28 15:09   ` [PATCH v4 3/5] net/mlx5: create NAT64 actions during configuration Bing Zhao
2024-02-28 15:09   ` [PATCH v4 4/5] net/mlx5: add NAT64 action support in rule creation Bing Zhao
2024-02-28 15:09   ` [PATCH v4 5/5] net/mlx5: validate the actions combination with NAT64 Bing Zhao
2024-02-29 10:39   ` [PATCH v4 0/5] NAT64 support in mlx5 PMD Raslan Darawsheh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240131093804.357465-2-bingz@nvidia.com \
    --to=bingz@nvidia.com \
    --cc=aman.deep.singh@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=ferruh.yigit@amd.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=suanmingm@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=yuying.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).