All of lore.kernel.org
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode
@ 2021-04-08  8:17 Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 1/4] crypto/octeontx2: add UDP encapsulation support Tejasree Kondoj
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:17 UTC (permalink / raw)
  To: Akhil Goyal, Radu Nicolau
  Cc: Tejasree Kondoj, Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev

This series adds lookaside IPsec UDP encapsulation and
transport mode support.
The functionality has been tested with ipsec-secgw application
running in lookaside protocol offload mode.

v3:
* Supported UDP encapsulation for IPv6 packets
* Fixed if condition

v2:
* Supported per SA UDP encapsulation in ipsec-secgw
* Added new packet type for UDP-ESP packets in mbuf

Tejasree Kondoj (4):
  crypto/octeontx2: add UDP encapsulation support
  mbuf: add packet type for UDP-ESP tunnel packets
  examples/ipsec-secgw: add UDP encapsulation support
  crypto/octeontx2: support lookaside IPv4 transport mode

 doc/guides/cryptodevs/octeontx2.rst           |   2 +
 doc/guides/rel_notes/release_21_05.rst        |  14 ++
 doc/guides/sample_app_ug/ipsec_secgw.rst      |  15 +-
 drivers/crypto/octeontx2/otx2_cryptodev_ops.c |   7 +-
 drivers/crypto/octeontx2/otx2_cryptodev_sec.c | 145 +++++++++---------
 drivers/crypto/octeontx2/otx2_cryptodev_sec.h |   4 +-
 drivers/crypto/octeontx2/otx2_ipsec_po.h      |   6 +
 drivers/crypto/octeontx2/otx2_ipsec_po_ops.h  |   8 +-
 examples/ipsec-secgw/ipsec-secgw.c            |  49 +++++-
 examples/ipsec-secgw/ipsec-secgw.h            |   2 +
 examples/ipsec-secgw/ipsec.c                  |   9 ++
 examples/ipsec-secgw/ipsec.h                  |   2 +
 examples/ipsec-secgw/sa.c                     |  18 +++
 examples/ipsec-secgw/sad.h                    |   6 +-
 lib/librte_mbuf/rte_mbuf_ptype.h              |  21 +++
 15 files changed, 218 insertions(+), 90 deletions(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [dpdk-dev] [PATCH v3 1/4] crypto/octeontx2: add UDP encapsulation support
  2021-04-08  8:17 [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
@ 2021-04-08  8:17 ` Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Tejasree Kondoj
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:17 UTC (permalink / raw)
  To: Akhil Goyal, Radu Nicolau
  Cc: Tejasree Kondoj, Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev

Adding UDP encapsulation support for IPsec in
lookaside protocol mode.

Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
---
 doc/guides/cryptodevs/octeontx2.rst           |  1 +
 doc/guides/rel_notes/release_21_05.rst        |  2 +
 drivers/crypto/octeontx2/otx2_cryptodev_sec.c | 59 ++++++++-----------
 3 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/doc/guides/cryptodevs/octeontx2.rst b/doc/guides/cryptodevs/octeontx2.rst
index 8c7df065b3..00226a8c77 100644
--- a/doc/guides/cryptodevs/octeontx2.rst
+++ b/doc/guides/cryptodevs/octeontx2.rst
@@ -181,6 +181,7 @@ Features supported
 * Tunnel mode
 * ESN
 * Anti-replay
+* UDP Encapsulation
 * AES-128/192/256-GCM
 * AES-128/192/256-CBC-SHA1-HMAC
 * AES-128/192/256-CBC-SHA256-128-HMAC
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index a80ce8ca12..5565c7637c 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -126,6 +126,8 @@ New Features
 * **Updated the OCTEON TX2 crypto PMD.**
 
   * Added support for DIGEST_ENCRYPTED mode in OCTEON TX2 crypto PMD.
+  * Updated the OCTEON TX2 crypto PMD lookaside protocol offload for IPsec with
+    UDP encapsulation support for NAT Traversal.
 
 * **Updated testpmd.**
 
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
index 342f089df8..210c53aa0a 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
@@ -203,6 +203,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				     struct rte_security_session *sec_sess)
 {
 	struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
+	struct otx2_ipsec_po_ip_template *template;
 	const uint8_t *cipher_key, *auth_key;
 	struct otx2_sec_session_ipsec_lp *lp;
 	struct otx2_ipsec_po_sa_ctl *ctl;
@@ -248,11 +249,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 		if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV4) {
 
 			if (ctl->enc_type == OTX2_IPSEC_PO_SA_ENC_AES_GCM) {
-				if (ipsec->options.udp_encap) {
-					sa->aes_gcm.template.ip4.udp_src = 4500;
-					sa->aes_gcm.template.ip4.udp_dst = 4500;
-				}
-				ip = &sa->aes_gcm.template.ip4.ipv4_hdr;
+				template = &sa->aes_gcm.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						aes_gcm.template) + sizeof(
 						sa->aes_gcm.template.ip4);
@@ -260,11 +257,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				lp->ctx_len = ctx_len >> 3;
 			} else if (ctl->auth_type ==
 					OTX2_IPSEC_PO_SA_AUTH_SHA1) {
-				if (ipsec->options.udp_encap) {
-					sa->sha1.template.ip4.udp_src = 4500;
-					sa->sha1.template.ip4.udp_dst = 4500;
-				}
-				ip = &sa->sha1.template.ip4.ipv4_hdr;
+				template = &sa->sha1.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						sha1.template) + sizeof(
 						sa->sha1.template.ip4);
@@ -272,11 +265,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				lp->ctx_len = ctx_len >> 3;
 			} else if (ctl->auth_type ==
 					OTX2_IPSEC_PO_SA_AUTH_SHA2_256) {
-				if (ipsec->options.udp_encap) {
-					sa->sha2.template.ip4.udp_src = 4500;
-					sa->sha2.template.ip4.udp_dst = 4500;
-				}
-				ip = &sa->sha2.template.ip4.ipv4_hdr;
+				template = &sa->sha2.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						sha2.template) + sizeof(
 						sa->sha2.template.ip4);
@@ -285,8 +274,15 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 			} else {
 				return -EINVAL;
 			}
+			ip = &template->ip4.ipv4_hdr;
+			if (ipsec->options.udp_encap) {
+				ip->next_proto_id = IPPROTO_UDP;
+				template->ip4.udp_src = rte_be_to_cpu_16(4500);
+				template->ip4.udp_dst = rte_be_to_cpu_16(4500);
+			} else {
+				ip->next_proto_id = IPPROTO_ESP;
+			}
 			ip->version_ihl = RTE_IPV4_VHL_DEF;
-			ip->next_proto_id = IPPROTO_ESP;
 			ip->time_to_live = ipsec->tunnel.ipv4.ttl;
 			ip->type_of_service |= (ipsec->tunnel.ipv4.dscp << 2);
 			if (ipsec->tunnel.ipv4.df)
@@ -299,11 +295,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				RTE_SECURITY_IPSEC_TUNNEL_IPV6) {
 
 			if (ctl->enc_type == OTX2_IPSEC_PO_SA_ENC_AES_GCM) {
-				if (ipsec->options.udp_encap) {
-					sa->aes_gcm.template.ip6.udp_src = 4500;
-					sa->aes_gcm.template.ip6.udp_dst = 4500;
-				}
-				ip6 = &sa->aes_gcm.template.ip6.ipv6_hdr;
+				template = &sa->aes_gcm.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						aes_gcm.template) + sizeof(
 						sa->aes_gcm.template.ip6);
@@ -311,11 +303,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				lp->ctx_len = ctx_len >> 3;
 			} else if (ctl->auth_type ==
 					OTX2_IPSEC_PO_SA_AUTH_SHA1) {
-				if (ipsec->options.udp_encap) {
-					sa->sha1.template.ip6.udp_src = 4500;
-					sa->sha1.template.ip6.udp_dst = 4500;
-				}
-				ip6 = &sa->sha1.template.ip6.ipv6_hdr;
+				template = &sa->sha1.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						sha1.template) + sizeof(
 						sa->sha1.template.ip6);
@@ -323,11 +311,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				lp->ctx_len = ctx_len >> 3;
 			} else if (ctl->auth_type ==
 					OTX2_IPSEC_PO_SA_AUTH_SHA2_256) {
-				if (ipsec->options.udp_encap) {
-					sa->sha2.template.ip6.udp_src = 4500;
-					sa->sha2.template.ip6.udp_dst = 4500;
-				}
-				ip6 = &sa->sha2.template.ip6.ipv6_hdr;
+				template = &sa->sha2.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
 						sha2.template) + sizeof(
 						sa->sha2.template.ip6);
@@ -337,6 +321,16 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				return -EINVAL;
 			}
 
+			ip6 = &template->ip6.ipv6_hdr;
+			if (ipsec->options.udp_encap) {
+				ip6->proto = IPPROTO_UDP;
+				template->ip6.udp_src = rte_be_to_cpu_16(4500);
+				template->ip6.udp_dst = rte_be_to_cpu_16(4500);
+			} else {
+				ip6->proto = (ipsec->proto ==
+					RTE_SECURITY_IPSEC_SA_PROTO_ESP) ?
+					IPPROTO_ESP : IPPROTO_AH;
+			}
 			ip6->vtc_flow = rte_cpu_to_be_32(0x60000000 |
 				((ipsec->tunnel.ipv6.dscp <<
 					RTE_IPV6_HDR_TC_SHIFT) &
@@ -345,9 +339,6 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 					RTE_IPV6_HDR_FL_SHIFT) &
 					RTE_IPV6_HDR_FL_MASK));
 			ip6->hop_limits = ipsec->tunnel.ipv6.hlimit;
-			ip6->proto = (ipsec->proto ==
-					RTE_SECURITY_IPSEC_SA_PROTO_ESP) ?
-					IPPROTO_ESP : IPPROTO_AH;
 			memcpy(&ip6->src_addr, &ipsec->tunnel.ipv6.src_addr,
 				sizeof(struct in6_addr));
 			memcpy(&ip6->dst_addr, &ipsec->tunnel.ipv6.dst_addr,
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-08  8:17 [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 1/4] crypto/octeontx2: add UDP encapsulation support Tejasree Kondoj
@ 2021-04-08  8:17 ` Tejasree Kondoj
  2021-04-08  8:33   ` Tejasree Kondoj
  2021-04-08 11:10   ` Olivier Matz
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 4/4] crypto/octeontx2: support lookaside IPv4 transport mode Tejasree Kondoj
  3 siblings, 2 replies; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:17 UTC (permalink / raw)
  To: Akhil Goyal, Radu Nicolau, Konstantin Ananyev
  Cc: Tejasree Kondoj, Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev

Adding new mbuf packet type for UDP encapsulated
ESP packets.

Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
---
 doc/guides/rel_notes/release_21_05.rst |  5 +++++
 lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 5565c7637c..c9e9e2ec22 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -55,6 +55,11 @@ New Features
      Also, make sure to start the actual text at the margin.
      =======================================================
 
+* **Added new packet type for UDP-ESP packets in mbuf.**
+
+  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can be
+  used to identify UDP encapsulated ESP packets.
+
 * **Enhanced ethdev representor syntax.**
 
   * Introduced representor type of VF, SF and PF.
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 17a2dd3576..bf92ce0c1a 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -491,6 +491,27 @@ extern "C" {
  * | 'destination port'=6635>
  */
 #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
+/**
+ * ESP-in-UDP tunneling packet type (RFC 3948).
+ *
+ * Packet format:
+ * <'ether type'=0x0800
+ * | 'version'=4, 'protocol'=17
+ * | 'destination port'=4500>
+ * or,
+ * <'ether type'=0x86DD
+ * | 'version'=6, 'next header'=17
+ * | 'destination port'=4500>
+ * or,
+ * <'ether type'=0x0800
+ * | 'version'=4, 'protocol'=17
+ * | 'source port'=4500>
+ * or,
+ * <'ether type'=0x86DD
+ * | 'version'=6, 'next header'=17
+ * | 'source port'=4500>
+ */
+#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
 /**
  * Mask of tunneling packet types.
  */
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support
  2021-04-08  8:17 [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 1/4] crypto/octeontx2: add UDP encapsulation support Tejasree Kondoj
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Tejasree Kondoj
@ 2021-04-08  8:17 ` Tejasree Kondoj
  2021-04-08 10:45   ` Ananyev, Konstantin
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 4/4] crypto/octeontx2: support lookaside IPv4 transport mode Tejasree Kondoj
  3 siblings, 1 reply; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:17 UTC (permalink / raw)
  To: Akhil Goyal, Radu Nicolau, Konstantin Ananyev
  Cc: Tejasree Kondoj, Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev

Adding lookaside IPsec UDP encapsulation support
for NAT traversal.
Application has to add udp-encap option to sa config file
to enable UDP encapsulation on the SA.

Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
---
 doc/guides/rel_notes/release_21_05.rst   |  5 +++
 doc/guides/sample_app_ug/ipsec_secgw.rst | 15 +++++++-
 examples/ipsec-secgw/ipsec-secgw.c       | 49 +++++++++++++++++++++---
 examples/ipsec-secgw/ipsec-secgw.h       |  2 +
 examples/ipsec-secgw/ipsec.c             |  9 +++++
 examples/ipsec-secgw/ipsec.h             |  2 +
 examples/ipsec-secgw/sa.c                | 18 +++++++++
 examples/ipsec-secgw/sad.h               |  6 ++-
 8 files changed, 98 insertions(+), 8 deletions(-)

diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index c9e9e2ec22..d71422c452 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -141,6 +141,11 @@ New Features
   * Added command to display Rx queue used descriptor count.
     ``show port (port_id) rxq (queue_id) desc used count``
 
+* **Updated ipsec-secgw sample application.**
+
+  * Updated the ``ipsec-secgw`` sample application with UDP encapsulation
+    support for NAT Traversal.
+
 
 Removed Items
 -------------
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 176e292d3f..2dc39aa50a 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -500,7 +500,7 @@ The SA rule syntax is shown as follows:
 
     sa <dir> <spi> <cipher_algo> <cipher_key> <auth_algo> <auth_key>
     <mode> <src_ip> <dst_ip> <action_type> <port_id> <fallback>
-    <flow-direction> <port_id> <queue_id>
+    <flow-direction> <port_id> <queue_id> <udp-encap>
 
 where each options means:
 
@@ -709,6 +709,17 @@ where each options means:
    * *port_id*: Port ID of the NIC for which the SA is configured.
    * *queue_id*: Queue ID to which traffic should be redirected.
 
+ ``<udp-encap>``
+
+ * Option to enable IPsec UDP encapsulation for NAT Traversal.
+   Only *lookaside-protocol-offload* mode is supported at the moment.
+
+ * Optional: Yes, it is disabled by default
+
+ * Syntax:
+
+   * *udp-encap*
+
 Example SA rules:
 
 .. code-block:: console
@@ -1023,4 +1034,4 @@ Available options:
 *   ``-h`` Show usage.
 
 If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 20d69ba813..0555d6d00f 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -184,7 +184,8 @@ static uint64_t frag_ttl_ns = MAX_FRAG_TTL_NS;
 /* application wide librte_ipsec/SA parameters */
 struct app_sa_prm app_sa_prm = {
 			.enable = 0,
-			.cache_sz = SA_CACHE_SZ
+			.cache_sz = SA_CACHE_SZ,
+			.udp_encap = 0
 		};
 static const char *cfgfile;
 
@@ -360,6 +361,9 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 	const struct rte_ether_hdr *eth;
 	const struct rte_ipv4_hdr *iph4;
 	const struct rte_ipv6_hdr *iph6;
+	const struct rte_udp_hdr *udp;
+	uint16_t ip4_hdr_len;
+	uint16_t nat_port;
 
 	eth = rte_pktmbuf_mtod(pkt, const struct rte_ether_hdr *);
 	if (eth->ether_type == rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
@@ -368,9 +372,28 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 			RTE_ETHER_HDR_LEN);
 		adjust_ipv4_pktlen(pkt, iph4, 0);
 
-		if (iph4->next_proto_id == IPPROTO_ESP)
+		switch (iph4->next_proto_id) {
+		case IPPROTO_ESP:
 			t->ipsec.pkts[(t->ipsec.num)++] = pkt;
-		else {
+			break;
+		case IPPROTO_UDP:
+			if (app_sa_prm.udp_encap == 1) {
+				ip4_hdr_len = ((iph4->version_ihl &
+					RTE_IPV4_HDR_IHL_MASK) *
+					RTE_IPV4_IHL_MULTIPLIER);
+				udp = rte_pktmbuf_mtod_offset(pkt,
+					struct rte_udp_hdr *, ip4_hdr_len);
+				nat_port = rte_cpu_to_be_16(IPSEC_NAT_T_PORT);
+				if (udp->src_port == nat_port ||
+					udp->dst_port == nat_port){
+					t->ipsec.pkts[(t->ipsec.num)++] = pkt;
+					pkt->packet_type |=
+						RTE_PTYPE_TUNNEL_ESP_IN_UDP;
+					break;
+				}
+			}
+		/* Fall through */
+		default:
 			t->ip4.data[t->ip4.num] = &iph4->next_proto_id;
 			t->ip4.pkts[(t->ip4.num)++] = pkt;
 		}
@@ -403,9 +426,25 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 			return;
 		}
 
-		if (next_proto == IPPROTO_ESP)
+		switch (iph6->proto) {
+		case IPPROTO_ESP:
 			t->ipsec.pkts[(t->ipsec.num)++] = pkt;
-		else {
+			break;
+		case IPPROTO_UDP:
+			if (app_sa_prm.udp_encap == 1) {
+				udp = rte_pktmbuf_mtod_offset(pkt,
+					struct rte_udp_hdr *, l3len);
+				nat_port = rte_cpu_to_be_16(IPSEC_NAT_T_PORT);
+				if (udp->src_port == nat_port ||
+					udp->dst_port == nat_port){
+					t->ipsec.pkts[(t->ipsec.num)++] = pkt;
+					pkt->packet_type |=
+						RTE_PTYPE_TUNNEL_ESP_IN_UDP;
+					break;
+				}
+			}
+		/* Fall through */
+		default:
 			t->ip6.data[t->ip6.num] = &iph6->proto;
 			t->ip6.pkts[(t->ip6.num)++] = pkt;
 		}
diff --git a/examples/ipsec-secgw/ipsec-secgw.h b/examples/ipsec-secgw/ipsec-secgw.h
index f2281e73cf..6887d752ab 100644
--- a/examples/ipsec-secgw/ipsec-secgw.h
+++ b/examples/ipsec-secgw/ipsec-secgw.h
@@ -47,6 +47,8 @@
 
 #define ETHADDR(a, b, c, d, e, f) (__BYTES_TO_UINT64(a, b, c, d, e, f, 0, 0))
 
+#define IPSEC_NAT_T_PORT 4500
+
 struct traffic_type {
 	const uint8_t *data[MAX_PKT_BURST * 2];
 	struct rte_mbuf *pkts[MAX_PKT_BURST * 2];
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 6baeeb342f..2d35536f57 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -52,6 +52,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
 	ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
 	ipsec->replay_win_sz = app_sa_prm.window_size;
 	ipsec->options.esn = app_sa_prm.enable_esn;
+	ipsec->options.udp_encap = sa->udp_encap;
 }
 
 int
@@ -556,6 +557,14 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 				continue;
 			}
 
+			if (unlikely((pkts[i]->packet_type &
+					RTE_PTYPE_TUNNEL_ESP_IN_UDP) ==
+					RTE_PTYPE_TUNNEL_ESP_IN_UDP &&
+					sa->udp_encap != 1)) {
+				free_pkts(&pkts[i], 1);
+				continue;
+			}
+
 			sym_cop = get_sym_cop(&priv->cop);
 			sym_cop->m_src = pkts[i];
 
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 7031e28c46..ae5058de27 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -75,6 +75,7 @@ struct app_sa_prm {
 	uint32_t window_size; /* replay window size */
 	uint32_t enable_esn;  /* enable/disable ESN support */
 	uint32_t cache_sz;	/* per lcore SA cache size */
+	uint32_t udp_encap;   /* enable/disable UDP Encapsulation */
 	uint64_t flags;       /* rte_ipsec_sa_prm.flags */
 };
 
@@ -136,6 +137,7 @@ struct ipsec_sa {
 		struct rte_security_ipsec_xform *sec_xform;
 	};
 	enum rte_security_ipsec_sa_direction direction;
+	uint8_t udp_encap;
 	uint16_t portid;
 	uint8_t fdir_qid;
 	uint8_t fdir_flag;
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index cd1397531a..7bb9ef36c2 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -298,6 +298,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
 	uint32_t portid_p = 0;
 	uint32_t fallback_p = 0;
 	int16_t status_p = 0;
+	uint16_t udp_encap_p = 0;
 
 	if (strcmp(tokens[0], "in") == 0) {
 		ri = &nb_sa_in;
@@ -757,6 +758,23 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
 			}
 			continue;
 		}
+		if (strcmp(tokens[ti], "udp-encap") == 0) {
+			APP_CHECK(ips->type ==
+				RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+				status, "UDP encapsulation is allowed if the "
+				"session is of type lookaside-protocol-offload "
+				"only.");
+			if (status->status < 0)
+				return;
+			APP_CHECK_PRESENCE(udp_encap_p, tokens[ti], status);
+			if (status->status < 0)
+				return;
+
+			rule->udp_encap = 1;
+			app_sa_prm.udp_encap = 1;
+			udp_encap_p = 1;
+			continue;
+		}
 
 		/* unrecognizeable input */
 		APP_CHECK(0, status, "unrecognized input \"%s\"",
diff --git a/examples/ipsec-secgw/sad.h b/examples/ipsec-secgw/sad.h
index 473aaa938e..751cf7afae 100644
--- a/examples/ipsec-secgw/sad.h
+++ b/examples/ipsec-secgw/sad.h
@@ -77,6 +77,7 @@ sad_lookup(struct ipsec_sad *sad, struct rte_mbuf *pkts[],
 	uint32_t spi, cache_idx;
 	struct ipsec_sad_cache *cache;
 	struct ipsec_sa *cached_sa;
+	uint16_t udp_hdr_len = 0;
 	int is_ipv4;
 
 	cache  = &RTE_PER_LCORE(sad_cache);
@@ -85,8 +86,11 @@ sad_lookup(struct ipsec_sad *sad, struct rte_mbuf *pkts[],
 	for (i = 0; i < nb_pkts; i++) {
 		ipv4 = rte_pktmbuf_mtod(pkts[i], struct rte_ipv4_hdr *);
 		ipv6 = rte_pktmbuf_mtod(pkts[i], struct rte_ipv6_hdr *);
+		if ((pkts[i]->packet_type & RTE_PTYPE_TUNNEL_ESP_IN_UDP) ==
+				RTE_PTYPE_TUNNEL_ESP_IN_UDP)
+			udp_hdr_len = sizeof(struct rte_udp_hdr);
 		esp = rte_pktmbuf_mtod_offset(pkts[i], struct rte_esp_hdr *,
-				pkts[i]->l3_len);
+				pkts[i]->l3_len + udp_hdr_len);
 
 		is_ipv4 = pkts[i]->packet_type & RTE_PTYPE_L3_IPV4;
 		spi = rte_be_to_cpu_32(esp->spi);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [dpdk-dev] [PATCH v3 4/4] crypto/octeontx2: support lookaside IPv4 transport mode
  2021-04-08  8:17 [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
                   ` (2 preceding siblings ...)
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support Tejasree Kondoj
@ 2021-04-08  8:17 ` Tejasree Kondoj
  3 siblings, 0 replies; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:17 UTC (permalink / raw)
  To: Akhil Goyal, Radu Nicolau
  Cc: Tejasree Kondoj, Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev

Adding support for IPv4 lookaside IPsec transport mode.

Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
---
 doc/guides/cryptodevs/octeontx2.rst           |   1 +
 doc/guides/rel_notes/release_21_05.rst        |   2 +
 drivers/crypto/octeontx2/otx2_cryptodev_ops.c |   7 +-
 drivers/crypto/octeontx2/otx2_cryptodev_sec.c | 110 ++++++++++--------
 drivers/crypto/octeontx2/otx2_cryptodev_sec.h |   4 +-
 drivers/crypto/octeontx2/otx2_ipsec_po.h      |   6 +
 drivers/crypto/octeontx2/otx2_ipsec_po_ops.h  |   8 +-
 7 files changed, 78 insertions(+), 60 deletions(-)

diff --git a/doc/guides/cryptodevs/octeontx2.rst b/doc/guides/cryptodevs/octeontx2.rst
index 00226a8c77..f0beb92a49 100644
--- a/doc/guides/cryptodevs/octeontx2.rst
+++ b/doc/guides/cryptodevs/octeontx2.rst
@@ -179,6 +179,7 @@ Features supported
 * IPv6
 * ESP
 * Tunnel mode
+* Transport mode(IPv4)
 * ESN
 * Anti-replay
 * UDP Encapsulation
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index d71422c452..a0cc3f6cad 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -133,6 +133,8 @@ New Features
   * Added support for DIGEST_ENCRYPTED mode in OCTEON TX2 crypto PMD.
   * Updated the OCTEON TX2 crypto PMD lookaside protocol offload for IPsec with
     UDP encapsulation support for NAT Traversal.
+  * Updated the OCTEON TX2 crypto PMD lookaside protocol offload for IPsec with
+    IPv4 transport mode support.
 
 * **Updated testpmd.**
 
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index fc4d5bac49..31dd0d7f7c 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -932,7 +932,7 @@ otx2_cpt_sec_post_process(struct rte_crypto_op *cop, uintptr_t *rsp)
 	struct rte_mbuf *m = sym_op->m_src;
 	struct rte_ipv6_hdr *ip6;
 	struct rte_ipv4_hdr *ip;
-	uint16_t m_len;
+	uint16_t m_len = 0;
 	int mdata_len;
 	char *data;
 
@@ -942,11 +942,12 @@ otx2_cpt_sec_post_process(struct rte_crypto_op *cop, uintptr_t *rsp)
 	if (word0->s.opcode.major == OTX2_IPSEC_PO_PROCESS_IPSEC_INB) {
 		data = rte_pktmbuf_mtod(m, char *);
 
-		if (rsp[4] == RTE_SECURITY_IPSEC_TUNNEL_IPV4) {
+		if (rsp[4] == OTX2_IPSEC_PO_TRANSPORT ||
+		    rsp[4] == OTX2_IPSEC_PO_TUNNEL_IPV4) {
 			ip = (struct rte_ipv4_hdr *)(data +
 				OTX2_IPSEC_PO_INB_RPTR_HDR);
 			m_len = rte_be_to_cpu_16(ip->total_length);
-		} else {
+		} else if (rsp[4] == OTX2_IPSEC_PO_TUNNEL_IPV6) {
 			ip6 = (struct rte_ipv6_hdr *)(data +
 				OTX2_IPSEC_PO_INB_RPTR_HDR);
 			m_len = rte_be_to_cpu_16(ip6->payload_len) +
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
index 210c53aa0a..3c5686a42c 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
@@ -25,12 +25,15 @@ ipsec_lp_len_precalc(struct rte_security_ipsec_xform *ipsec,
 {
 	struct rte_crypto_sym_xform *cipher_xform, *auth_xform;
 
-	if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV4)
-		lp->partial_len = sizeof(struct rte_ipv4_hdr);
-	else if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV6)
-		lp->partial_len = sizeof(struct rte_ipv6_hdr);
-	else
-		return -EINVAL;
+	lp->partial_len = 0;
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV4)
+			lp->partial_len = sizeof(struct rte_ipv4_hdr);
+		else if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV6)
+			lp->partial_len = sizeof(struct rte_ipv6_hdr);
+		else
+			return -EINVAL;
+	}
 
 	if (ipsec->proto == RTE_SECURITY_IPSEC_SA_PROTO_ESP) {
 		lp->partial_len += sizeof(struct rte_esp_hdr);
@@ -203,7 +206,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				     struct rte_security_session *sec_sess)
 {
 	struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
-	struct otx2_ipsec_po_ip_template *template;
+	struct otx2_ipsec_po_ip_template *template = NULL;
 	const uint8_t *cipher_key, *auth_key;
 	struct otx2_sec_session_ipsec_lp *lp;
 	struct otx2_ipsec_po_sa_ctl *ctl;
@@ -229,10 +232,10 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 	memset(sa, 0, sizeof(struct otx2_ipsec_po_out_sa));
 
 	/* Initialize lookaside ipsec private data */
+	lp->mode_type = OTX2_IPSEC_PO_TRANSPORT;
 	lp->ip_id = 0;
 	lp->seq_lo = 1;
 	lp->seq_hi = 0;
-	lp->tunnel_type = ipsec->tunnel.type;
 
 	ret = ipsec_po_sa_ctl_set(ipsec, crypto_xform, ctl);
 	if (ret)
@@ -242,46 +245,47 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 	if (ret)
 		return ret;
 
-	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-		/* Start ip id from 1 */
-		lp->ip_id = 1;
+	/* Start ip id from 1 */
+	lp->ip_id = 1;
+
+	if (ctl->enc_type == OTX2_IPSEC_PO_SA_ENC_AES_GCM) {
+		template = &sa->aes_gcm.template;
+		ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
+				aes_gcm.template) + sizeof(
+				sa->aes_gcm.template.ip4);
+		ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
+		lp->ctx_len = ctx_len >> 3;
+	} else if (ctl->auth_type ==
+			OTX2_IPSEC_PO_SA_AUTH_SHA1) {
+		template = &sa->sha1.template;
+		ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
+				sha1.template) + sizeof(
+				sa->sha1.template.ip4);
+		ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
+		lp->ctx_len = ctx_len >> 3;
+	} else if (ctl->auth_type ==
+			OTX2_IPSEC_PO_SA_AUTH_SHA2_256) {
+		template = &sa->sha2.template;
+		ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
+				sha2.template) + sizeof(
+				sa->sha2.template.ip4);
+		ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
+		lp->ctx_len = ctx_len >> 3;
+	} else {
+		return -EINVAL;
+	}
+	ip = &template->ip4.ipv4_hdr;
+	if (ipsec->options.udp_encap) {
+		ip->next_proto_id = IPPROTO_UDP;
+		template->ip4.udp_src = rte_be_to_cpu_16(4500);
+		template->ip4.udp_dst = rte_be_to_cpu_16(4500);
+	} else {
+		ip->next_proto_id = IPPROTO_ESP;
+	}
 
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
 		if (ipsec->tunnel.type == RTE_SECURITY_IPSEC_TUNNEL_IPV4) {
-
-			if (ctl->enc_type == OTX2_IPSEC_PO_SA_ENC_AES_GCM) {
-				template = &sa->aes_gcm.template;
-				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
-						aes_gcm.template) + sizeof(
-						sa->aes_gcm.template.ip4);
-				ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
-				lp->ctx_len = ctx_len >> 3;
-			} else if (ctl->auth_type ==
-					OTX2_IPSEC_PO_SA_AUTH_SHA1) {
-				template = &sa->sha1.template;
-				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
-						sha1.template) + sizeof(
-						sa->sha1.template.ip4);
-				ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
-				lp->ctx_len = ctx_len >> 3;
-			} else if (ctl->auth_type ==
-					OTX2_IPSEC_PO_SA_AUTH_SHA2_256) {
-				template = &sa->sha2.template;
-				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
-						sha2.template) + sizeof(
-						sa->sha2.template.ip4);
-				ctx_len = RTE_ALIGN_CEIL(ctx_len, 8);
-				lp->ctx_len = ctx_len >> 3;
-			} else {
-				return -EINVAL;
-			}
-			ip = &template->ip4.ipv4_hdr;
-			if (ipsec->options.udp_encap) {
-				ip->next_proto_id = IPPROTO_UDP;
-				template->ip4.udp_src = rte_be_to_cpu_16(4500);
-				template->ip4.udp_dst = rte_be_to_cpu_16(4500);
-			} else {
-				ip->next_proto_id = IPPROTO_ESP;
-			}
+			lp->mode_type = OTX2_IPSEC_PO_TUNNEL_IPV4;
 			ip->version_ihl = RTE_IPV4_VHL_DEF;
 			ip->time_to_live = ipsec->tunnel.ipv4.ttl;
 			ip->type_of_service |= (ipsec->tunnel.ipv4.dscp << 2);
@@ -294,6 +298,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 		} else if (ipsec->tunnel.type ==
 				RTE_SECURITY_IPSEC_TUNNEL_IPV6) {
 
+			lp->mode_type = OTX2_IPSEC_PO_TUNNEL_IPV6;
 			if (ctl->enc_type == OTX2_IPSEC_PO_SA_ENC_AES_GCM) {
 				template = &sa->aes_gcm.template;
 				ctx_len = offsetof(struct otx2_ipsec_po_out_sa,
@@ -343,11 +348,7 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
 				sizeof(struct in6_addr));
 			memcpy(&ip6->dst_addr, &ipsec->tunnel.ipv6.dst_addr,
 				sizeof(struct in6_addr));
-		} else {
-			return -EINVAL;
 		}
-	} else {
-		return -EINVAL;
 	}
 
 	cipher_xform = crypto_xform;
@@ -428,13 +429,20 @@ crypto_sec_ipsec_inb_session_create(struct rte_cryptodev *crypto_dev,
 	if (ret)
 		return ret;
 
-	lp->tunnel_type = ipsec->tunnel.type;
+	lp->mode_type = OTX2_IPSEC_PO_TRANSPORT;
+
 	auth_xform = crypto_xform;
 	cipher_xform = crypto_xform->next;
 
 	cipher_key_len = 0;
 	auth_key_len = 0;
 
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL)
+		lp->mode_type = (ipsec->tunnel.type ==
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4) ?
+				OTX2_IPSEC_PO_TUNNEL_IPV4 :
+				OTX2_IPSEC_PO_TUNNEL_IPV6;
+
 	if (crypto_xform->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
 		if (crypto_xform->aead.algo == RTE_CRYPTO_AEAD_AES_GCM)
 			memcpy(sa->iv.gcm.nonce, &ipsec->salt, 4);
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_sec.h b/drivers/crypto/octeontx2/otx2_cryptodev_sec.h
index 2849c1ab75..87f55c97fe 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_sec.h
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_sec.h
@@ -55,8 +55,8 @@ struct otx2_sec_session_ipsec_lp {
 	uint8_t iv_length;
 	/** Auth IV length in bytes */
 	uint8_t auth_iv_length;
-	/** IPsec tunnel type */
-	enum rte_security_ipsec_tunnel_type tunnel_type;
+	/** IPsec mode and tunnel type */
+	enum otx2_ipsec_po_mode_type mode_type;
 };
 
 int otx2_crypto_sec_ctx_create(struct rte_cryptodev *crypto_dev);
diff --git a/drivers/crypto/octeontx2/otx2_ipsec_po.h b/drivers/crypto/octeontx2/otx2_ipsec_po.h
index eda9f19738..b3e7456551 100644
--- a/drivers/crypto/octeontx2/otx2_ipsec_po.h
+++ b/drivers/crypto/octeontx2/otx2_ipsec_po.h
@@ -20,6 +20,12 @@
 
 #define OTX2_IPSEC_PO_INB_RPTR_HDR         0x8
 
+enum otx2_ipsec_po_mode_type {
+	OTX2_IPSEC_PO_TRANSPORT = 1,
+	OTX2_IPSEC_PO_TUNNEL_IPV4,
+	OTX2_IPSEC_PO_TUNNEL_IPV6,
+};
+
 enum otx2_ipsec_po_comp_e {
 	OTX2_IPSEC_PO_CC_SUCCESS = 0x00,
 	OTX2_IPSEC_PO_CC_AUTH_UNSUPPORTED = 0xB0,
diff --git a/drivers/crypto/octeontx2/otx2_ipsec_po_ops.h b/drivers/crypto/octeontx2/otx2_ipsec_po_ops.h
index f4cab19811..58b199f4f3 100644
--- a/drivers/crypto/octeontx2/otx2_ipsec_po_ops.h
+++ b/drivers/crypto/octeontx2/otx2_ipsec_po_ops.h
@@ -26,7 +26,7 @@ otx2_ipsec_po_out_rlen_get(struct otx2_sec_session_ipsec_lp *sess,
 
 static __rte_always_inline struct cpt_request_info *
 alloc_request_struct(char *maddr, void *cop, int mdata_len,
-		     enum rte_security_ipsec_tunnel_type tunnel_type)
+		     enum otx2_ipsec_po_mode_type mode_type)
 {
 	struct cpt_request_info *req;
 	struct cpt_meta_info *meta;
@@ -48,7 +48,7 @@ alloc_request_struct(char *maddr, void *cop, int mdata_len,
 	op[1] = (uintptr_t)cop;
 	op[2] = (uintptr_t)req;
 	op[3] = mdata_len;
-	op[4] = tunnel_type;
+	op[4] = mode_type;
 
 	return req;
 }
@@ -89,7 +89,7 @@ process_outb_sa(struct rte_crypto_op *cop,
 
 	mdata += extend_tail; /* mdata follows encrypted data */
 	req = alloc_request_struct(mdata, (void *)cop, mdata_len,
-		sess->tunnel_type);
+		sess->mode_type);
 
 	data = rte_pktmbuf_prepend(m_src, extend_head);
 	if (unlikely(data == NULL)) {
@@ -162,7 +162,7 @@ process_inb_sa(struct rte_crypto_op *cop,
 	}
 
 	req = alloc_request_struct(mdata, (void *)cop, mdata_len,
-		sess->tunnel_type);
+		sess->mode_type);
 
 	/* Prepare CPT instruction */
 	word0.u64 = sess->ucmd_w0;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Tejasree Kondoj
@ 2021-04-08  8:33   ` Tejasree Kondoj
  2021-04-08 11:10   ` Olivier Matz
  1 sibling, 0 replies; 11+ messages in thread
From: Tejasree Kondoj @ 2021-04-08  8:33 UTC (permalink / raw)
  To: Tejasree Kondoj, Akhil Goyal, Radu Nicolau, Konstantin Ananyev,
	olivier.matz, andrew.rybchenko
  Cc: Anoob Joseph, Ankur Dwivedi, Jerin Jacob Kollanukkaran, dev,
	Ferruh Yigit, NBU-Contact-Thomas Monjalon

Hi Olivier, Andrew

Could you please review the patch?

Thanks
Tejasree

> -----Original Message-----
> From: Tejasree Kondoj <ktejasree@marvell.com>
> Sent: Thursday, April 8, 2021 1:47 PM
> To: Akhil Goyal <gakhil@marvell.com>; Radu Nicolau
> <radu.nicolau@intel.com>; Konstantin Ananyev
> <konstantin.ananyev@intel.com>
> Cc: Tejasree Kondoj <ktejasree@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org
> Subject: [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
> 
> Adding new mbuf packet type for UDP encapsulated ESP packets.
> 
> Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> ---
>  doc/guides/rel_notes/release_21_05.rst |  5 +++++
>  lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 5565c7637c..c9e9e2ec22 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -55,6 +55,11 @@ New Features
>       Also, make sure to start the actual text at the margin.
>       =======================================================
> 
> +* **Added new packet type for UDP-ESP packets in mbuf.**
> +
> +  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can be
> + used to identify UDP encapsulated ESP packets.
> +
>  * **Enhanced ethdev representor syntax.**
> 
>    * Introduced representor type of VF, SF and PF.
> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
> b/lib/librte_mbuf/rte_mbuf_ptype.h
> index 17a2dd3576..bf92ce0c1a 100644
> --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> @@ -491,6 +491,27 @@ extern "C" {
>   * | 'destination port'=6635>
>   */
>  #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
> +/**
> + * ESP-in-UDP tunneling packet type (RFC 3948).
> + *
> + * Packet format:
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=17
> + * | 'destination port'=4500>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=17
> + * | 'destination port'=4500>
> + * or,
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=17
> + * | 'source port'=4500>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=17
> + * | 'source port'=4500>
> + */
> +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
>  /**
>   * Mask of tunneling packet types.
>   */
> --
> 2.27.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support Tejasree Kondoj
@ 2021-04-08 10:45   ` Ananyev, Konstantin
  0 siblings, 0 replies; 11+ messages in thread
From: Ananyev, Konstantin @ 2021-04-08 10:45 UTC (permalink / raw)
  To: Tejasree Kondoj, Akhil Goyal, Nicolau, Radu
  Cc: Anoob Joseph, Ankur Dwivedi, Jerin Jacob, dev



> Adding lookaside IPsec UDP encapsulation support
> for NAT traversal.
> Application has to add udp-encap option to sa config file
> to enable UDP encapsulation on the SA.
> 
> Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> ---

Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

> 2.27.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Tejasree Kondoj
  2021-04-08  8:33   ` Tejasree Kondoj
@ 2021-04-08 11:10   ` Olivier Matz
  2021-04-09 10:56     ` [dpdk-dev] [EXT] " Akhil Goyal
  1 sibling, 1 reply; 11+ messages in thread
From: Olivier Matz @ 2021-04-08 11:10 UTC (permalink / raw)
  To: Tejasree Kondoj
  Cc: Akhil Goyal, Radu Nicolau, Konstantin Ananyev, Anoob Joseph,
	Ankur Dwivedi, Jerin Jacob, dev

On Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote:
> Adding new mbuf packet type for UDP encapsulated
> ESP packets.
> 
> Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> ---
>  doc/guides/rel_notes/release_21_05.rst |  5 +++++
>  lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
> index 5565c7637c..c9e9e2ec22 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -55,6 +55,11 @@ New Features
>       Also, make sure to start the actual text at the margin.
>       =======================================================
>  
> +* **Added new packet type for UDP-ESP packets in mbuf.**
> +
> +  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can be
> +  used to identify UDP encapsulated ESP packets.
> +
>  * **Enhanced ethdev representor syntax.**
>  
>    * Introduced representor type of VF, SF and PF.
> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
> index 17a2dd3576..bf92ce0c1a 100644
> --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> @@ -491,6 +491,27 @@ extern "C" {
>   * | 'destination port'=6635>
>   */
>  #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
> +/**
> + * ESP-in-UDP tunneling packet type (RFC 3948).
> + *
> + * Packet format:
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=17
> + * | 'destination port'=4500>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=17
> + * | 'destination port'=4500>
> + * or,
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=17
> + * | 'source port'=4500>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=17
> + * | 'source port'=4500>
> + */
> +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
>  /**
>   * Mask of tunneling packet types.
>   */

We arrive at the end of the values in packet type tunnel types,
and there is another pending patch that needs another tunnel type.

As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about
trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using
the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE.

It is sensible, because it can be considered as an API change for
current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this
type is used by applications.

I think it is time to start thinking about how the packet_type
mbuf API can evolve to solve this issue.

By the way, the update of *rte_get_ptype_tunnel_name() is missing.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [EXT] Re: [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-08 11:10   ` Olivier Matz
@ 2021-04-09 10:56     ` Akhil Goyal
  2021-04-13 13:03       ` Akhil Goyal
  0 siblings, 1 reply; 11+ messages in thread
From: Akhil Goyal @ 2021-04-09 10:56 UTC (permalink / raw)
  To: Olivier Matz, Tejasree Kondoj, Konstantin Ananyev
  Cc: Radu Nicolau, Anoob Joseph, Ankur Dwivedi,
	Jerin Jacob Kollanukkaran, dev

Hi Olivier,
> On Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote:
> > Adding new mbuf packet type for UDP encapsulated
> > ESP packets.
> >
> > Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> > ---
> >  doc/guides/rel_notes/release_21_05.rst |  5 +++++
> >  lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
> >  2 files changed, 26 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> > index 5565c7637c..c9e9e2ec22 100644
> > --- a/doc/guides/rel_notes/release_21_05.rst
> > +++ b/doc/guides/rel_notes/release_21_05.rst
> > @@ -55,6 +55,11 @@ New Features
> >       Also, make sure to start the actual text at the margin.
> >       =======================================================
> >
> > +* **Added new packet type for UDP-ESP packets in mbuf.**
> > +
> > +  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can
> be
> > +  used to identify UDP encapsulated ESP packets.
> > +
> >  * **Enhanced ethdev representor syntax.**
> >
> >    * Introduced representor type of VF, SF and PF.
> > diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
> b/lib/librte_mbuf/rte_mbuf_ptype.h
> > index 17a2dd3576..bf92ce0c1a 100644
> > --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> > +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> > @@ -491,6 +491,27 @@ extern "C" {
> >   * | 'destination port'=6635>
> >   */
> >  #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
> > +/**
> > + * ESP-in-UDP tunneling packet type (RFC 3948).
> > + *
> > + * Packet format:
> > + * <'ether type'=0x0800
> > + * | 'version'=4, 'protocol'=17
> > + * | 'destination port'=4500>
> > + * or,
> > + * <'ether type'=0x86DD
> > + * | 'version'=6, 'next header'=17
> > + * | 'destination port'=4500>
> > + * or,
> > + * <'ether type'=0x0800
> > + * | 'version'=4, 'protocol'=17
> > + * | 'source port'=4500>
> > + * or,
> > + * <'ether type'=0x86DD
> > + * | 'version'=6, 'next header'=17
> > + * | 'source port'=4500>
> > + */
> > +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
> >  /**
> >   * Mask of tunneling packet types.
> >   */
> 
> We arrive at the end of the values in packet type tunnel types,
> and there is another pending patch that needs another tunnel type.
> 
> As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about
> trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using
> the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE.
> 
> It is sensible, because it can be considered as an API change for
> current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this
> type is used by applications.

It is OK to use combination of these two but with an assumption
that a normal - IP-UDP packet when encrypted will be an IP-ESP packet
And L4 types are reset from the mbuf->packet_type by the driver.
@Konstantin Ananyev: Are you OK with this assumption?

And, if we choose this path, then also we may need a macro in this file,
So that application doesn't have to combine that explicitly for a standard use case.
#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       RTE_PTYPE_TUNNEL_ESP | RTE_PTYPE_L4_UDP

Will this be fine?

> 
> I think it is time to start thinking about how the packet_type
> mbuf API can evolve to solve this issue.
> 
> By the way, the update of *rte_get_ptype_tunnel_name() is missing.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [EXT] Re: [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-09 10:56     ` [dpdk-dev] [EXT] " Akhil Goyal
@ 2021-04-13 13:03       ` Akhil Goyal
  2021-04-13 15:46         ` Ananyev, Konstantin
  0 siblings, 1 reply; 11+ messages in thread
From: Akhil Goyal @ 2021-04-13 13:03 UTC (permalink / raw)
  To: Olivier Matz, Tejasree Kondoj, Konstantin Ananyev
  Cc: Radu Nicolau, Anoob Joseph, Ankur Dwivedi,
	Jerin Jacob Kollanukkaran, dev

 Hi Olivier/ Konstantin,
> > On Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote:
> > > Adding new mbuf packet type for UDP encapsulated
> > > ESP packets.
> > >
> > > Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> > > ---
> > >  doc/guides/rel_notes/release_21_05.rst |  5 +++++
> > >  lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
> > >  2 files changed, 26 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/release_21_05.rst
> > b/doc/guides/rel_notes/release_21_05.rst
> > > index 5565c7637c..c9e9e2ec22 100644
> > > --- a/doc/guides/rel_notes/release_21_05.rst
> > > +++ b/doc/guides/rel_notes/release_21_05.rst
> > > @@ -55,6 +55,11 @@ New Features
> > >       Also, make sure to start the actual text at the margin.
> > >       =======================================================
> > >
> > > +* **Added new packet type for UDP-ESP packets in mbuf.**
> > > +
> > > +  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can
> > be
> > > +  used to identify UDP encapsulated ESP packets.
> > > +
> > >  * **Enhanced ethdev representor syntax.**
> > >
> > >    * Introduced representor type of VF, SF and PF.
> > > diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
> > b/lib/librte_mbuf/rte_mbuf_ptype.h
> > > index 17a2dd3576..bf92ce0c1a 100644
> > > --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> > > +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> > > @@ -491,6 +491,27 @@ extern "C" {
> > >   * | 'destination port'=6635>
> > >   */
> > >  #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
> > > +/**
> > > + * ESP-in-UDP tunneling packet type (RFC 3948).
> > > + *
> > > + * Packet format:
> > > + * <'ether type'=0x0800
> > > + * | 'version'=4, 'protocol'=17
> > > + * | 'destination port'=4500>
> > > + * or,
> > > + * <'ether type'=0x86DD
> > > + * | 'version'=6, 'next header'=17
> > > + * | 'destination port'=4500>
> > > + * or,
> > > + * <'ether type'=0x0800
> > > + * | 'version'=4, 'protocol'=17
> > > + * | 'source port'=4500>
> > > + * or,
> > > + * <'ether type'=0x86DD
> > > + * | 'version'=6, 'next header'=17
> > > + * | 'source port'=4500>
> > > + */
> > > +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
> > >  /**
> > >   * Mask of tunneling packet types.
> > >   */
> >
> > We arrive at the end of the values in packet type tunnel types,
> > and there is another pending patch that needs another tunnel type.
> >
> > As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about
> > trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using
> > the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE.
> >
> > It is sensible, because it can be considered as an API change for
> > current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this
> > type is used by applications.
> 
> It is OK to use combination of these two but with an assumption
> that a normal - IP-UDP packet when encrypted will be an IP-ESP packet
> And L4 types are reset from the mbuf->packet_type by the driver.
> @Konstantin Ananyev: Are you OK with this assumption?
> 
> And, if we choose this path, then also we may need a macro in this file,
> So that application doesn't have to combine that explicitly for a standard use
> case.
> #define RTE_PTYPE_TUNNEL_ESP_IN_UDP       RTE_PTYPE_TUNNEL_ESP |
> RTE_PTYPE_L4_UDP
> 
> Will this be fine?
> 
Can we proceed with this approach?

Regards,
Akhil

> >
> > I think it is time to start thinking about how the packet_type
> > mbuf API can evolve to solve this issue.
> >
> > By the way, the update of *rte_get_ptype_tunnel_name() is missing.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [EXT] Re: [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets
  2021-04-13 13:03       ` Akhil Goyal
@ 2021-04-13 15:46         ` Ananyev, Konstantin
  0 siblings, 0 replies; 11+ messages in thread
From: Ananyev, Konstantin @ 2021-04-13 15:46 UTC (permalink / raw)
  To: Akhil Goyal, Olivier Matz, Tejasree Kondoj
  Cc: Nicolau, Radu, Anoob Joseph, Ankur Dwivedi,
	Jerin Jacob Kollanukkaran, dev

Hi Akhil,

> 
>  Hi Olivier/ Konstantin,
> > > On Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote:
> > > > Adding new mbuf packet type for UDP encapsulated
> > > > ESP packets.
> > > >
> > > > Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
> > > > ---
> > > >  doc/guides/rel_notes/release_21_05.rst |  5 +++++
> > > >  lib/librte_mbuf/rte_mbuf_ptype.h       | 21 +++++++++++++++++++++
> > > >  2 files changed, 26 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/release_21_05.rst
> > > b/doc/guides/rel_notes/release_21_05.rst
> > > > index 5565c7637c..c9e9e2ec22 100644
> > > > --- a/doc/guides/rel_notes/release_21_05.rst
> > > > +++ b/doc/guides/rel_notes/release_21_05.rst
> > > > @@ -55,6 +55,11 @@ New Features
> > > >       Also, make sure to start the actual text at the margin.
> > > >       =======================================================
> > > >
> > > > +* **Added new packet type for UDP-ESP packets in mbuf.**
> > > > +
> > > > +  Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can
> > > be
> > > > +  used to identify UDP encapsulated ESP packets.
> > > > +
> > > >  * **Enhanced ethdev representor syntax.**
> > > >
> > > >    * Introduced representor type of VF, SF and PF.
> > > > diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
> > > b/lib/librte_mbuf/rte_mbuf_ptype.h
> > > > index 17a2dd3576..bf92ce0c1a 100644
> > > > --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> > > > +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> > > > @@ -491,6 +491,27 @@ extern "C" {
> > > >   * | 'destination port'=6635>
> > > >   */
> > > >  #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP      0x0000d000
> > > > +/**
> > > > + * ESP-in-UDP tunneling packet type (RFC 3948).
> > > > + *
> > > > + * Packet format:
> > > > + * <'ether type'=0x0800
> > > > + * | 'version'=4, 'protocol'=17
> > > > + * | 'destination port'=4500>
> > > > + * or,
> > > > + * <'ether type'=0x86DD
> > > > + * | 'version'=6, 'next header'=17
> > > > + * | 'destination port'=4500>
> > > > + * or,
> > > > + * <'ether type'=0x0800
> > > > + * | 'version'=4, 'protocol'=17
> > > > + * | 'source port'=4500>
> > > > + * or,
> > > > + * <'ether type'=0x86DD
> > > > + * | 'version'=6, 'next header'=17
> > > > + * | 'source port'=4500>
> > > > + */
> > > > +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP       0x0000e000
> > > >  /**
> > > >   * Mask of tunneling packet types.
> > > >   */
> > >
> > > We arrive at the end of the values in packet type tunnel types,
> > > and there is another pending patch that needs another tunnel type.
> > >
> > > As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about
> > > trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using
> > > the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE.
> > >
> > > It is sensible, because it can be considered as an API change for
> > > current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this
> > > type is used by applications.
> >
> > It is OK to use combination of these two but with an assumption
> > that a normal - IP-UDP packet when encrypted will be an IP-ESP packet
> > And L4 types are reset from the mbuf->packet_type by the driver.
> > @Konstantin Ananyev: Are you OK with this assumption?
> >
> > And, if we choose this path, then also we may need a macro in this file,
> > So that application doesn't have to combine that explicitly for a standard use
> > case.
> > #define RTE_PTYPE_TUNNEL_ESP_IN_UDP       RTE_PTYPE_TUNNEL_ESP |
> > RTE_PTYPE_L4_UDP
> >
> > Will this be fine?
> >
> Can we proceed with this approach?

I think we can safely use such combination inside ipsec-secgw app.
About making it a new generic type - I am not so sure. 
As Olivier already pointed out - it looks like an API/behaviour breakage to me. 

> Regards,
> Akhil
> 
> > >
> > > I think it is time to start thinking about how the packet_type
> > > mbuf API can evolve to solve this issue.

+1
Might be it needs to be reworked completely.

> > >
> > > By the way, the update of *rte_get_ptype_tunnel_name() is missing.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-04-13 15:47 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-08  8:17 [dpdk-dev] [PATCH v3 0/4] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 1/4] crypto/octeontx2: add UDP encapsulation support Tejasree Kondoj
2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Tejasree Kondoj
2021-04-08  8:33   ` Tejasree Kondoj
2021-04-08 11:10   ` Olivier Matz
2021-04-09 10:56     ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-13 13:03       ` Akhil Goyal
2021-04-13 15:46         ` Ananyev, Konstantin
2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 3/4] examples/ipsec-secgw: add UDP encapsulation support Tejasree Kondoj
2021-04-08 10:45   ` Ananyev, Konstantin
2021-04-08  8:17 ` [dpdk-dev] [PATCH v3 4/4] crypto/octeontx2: support lookaside IPv4 transport mode Tejasree Kondoj

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.