* [PATCH] mbuf: add transport mode ESP packet type
@ 2024-08-22 15:32 Alexander Kozyrev
2024-09-02 8:43 ` Nithin Dabilpuram
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Kozyrev @ 2024-08-22 15:32 UTC (permalink / raw)
To: dev
Cc: dsosnowski, orika, nithind1988, olivier.matz, thomas, matan,
jerinj, rbhansali, ferruh.yigit
Support the IP Encapsulating Security Payload (ESP) in transport mode.
Currently, we have RTE_PTYPE_TUNNEL_ESP for the ESP tunnel mode.
Transport mode can be detected by parsing the "Next Header" field.
The Next Header is TCP for the transport mode and IP for the tunnel mode.
Add RTE_PTYPE_L4_ESP for the regular transport mode and
RTE_PTYPE_INNER_L4_ESP for the ESP over UDP packets.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
---
lib/mbuf/rte_mbuf_ptype.c | 2 ++
lib/mbuf/rte_mbuf_ptype.h | 36 ++++++++++++++++++++++++++++++------
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/lib/mbuf/rte_mbuf_ptype.c b/lib/mbuf/rte_mbuf_ptype.c
index d6f906b06c..ab180b3dda 100644
--- a/lib/mbuf/rte_mbuf_ptype.c
+++ b/lib/mbuf/rte_mbuf_ptype.c
@@ -50,6 +50,7 @@ const char *rte_get_ptype_l4_name(uint32_t ptype)
case RTE_PTYPE_L4_ICMP: return "L4_ICMP";
case RTE_PTYPE_L4_NONFRAG: return "L4_NONFRAG";
case RTE_PTYPE_L4_IGMP: return "L4_IGMP";
+ case RTE_PTYPE_L4_ESP: return "L4_ESP";
default: return "L4_UNKNOWN";
}
}
@@ -112,6 +113,7 @@ const char *rte_get_ptype_inner_l4_name(uint32_t ptype)
case RTE_PTYPE_INNER_L4_SCTP: return "INNER_L4_SCTP";
case RTE_PTYPE_INNER_L4_ICMP: return "INNER_L4_ICMP";
case RTE_PTYPE_INNER_L4_NONFRAG: return "INNER_L4_NONFRAG";
+ case RTE_PTYPE_INNER_L4_ESP: return "INNER_L4_ESP";
default: return "INNER_L4_UNKNOWN";
}
}
diff --git a/lib/mbuf/rte_mbuf_ptype.h b/lib/mbuf/rte_mbuf_ptype.h
index f2276e2909..c46a94f89f 100644
--- a/lib/mbuf/rte_mbuf_ptype.h
+++ b/lib/mbuf/rte_mbuf_ptype.h
@@ -247,7 +247,7 @@ extern "C" {
* It refers to those packets of any IP types, which can be recognized as
* fragmented. A fragmented packet cannot be recognized as any other L4 types
* (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP,
- * RTE_PTYPE_L4_NONFRAG).
+ * RTE_PTYPE_L4_NONFRAG, RTE_PTYPE_L4_IGMP, RTE_PTYPE_L4_ESP).
*
* Packet format:
* <'ether type'=0x0800
@@ -290,14 +290,15 @@ extern "C" {
*
* It refers to those packets of any IP types, while cannot be recognized as
* any of above L4 types (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP,
- * RTE_PTYPE_L4_FRAG, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP).
+ * RTE_PTYPE_L4_FRAG (for IPv6), RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP,
+ * RTE_PTYPE_L4_IGMP (for IPv4), RTE_PTYPE_L4_ESP).
*
* Packet format:
* <'ether type'=0x0800
- * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
+ * | 'version'=4, 'protocol'!=[1|2|6|17|50|132], 'MF'=0, 'frag_offset'=0>
* or,
* <'ether type'=0x86DD
- * | 'version'=6, 'next header'!=[6|17|44|132|1]>
+ * | 'version'=6, 'next header'!=[1|6|17|44|50|132]>
*/
#define RTE_PTYPE_L4_NONFRAG 0x00000600
/**
@@ -308,6 +309,17 @@ extern "C" {
* | 'version'=4, 'protocol'=2, 'MF'=0, 'frag_offset'=0>
*/
#define RTE_PTYPE_L4_IGMP 0x00000700
+/**
+ * ESP (IP Encapsulating Security Payload) transport packet type.
+ *
+ * Packet format:
+ * <'ether type'=0x0800
+ * | 'version'=4, 'protocol'=50, 'MF'=0, 'frag_offset'=0>
+ * or,
+ * <'ether type'=0x86DD
+ * | 'version'=6, 'next header'=50>
+ */
+#define RTE_PTYPE_L4_ESP 0x00000800
/**
* Mask of layer 4 packet types.
* It is used for outer packet for tunneling cases.
@@ -652,12 +664,24 @@ extern "C" {
*
* Packet format (inner only):
* <'ether type'=0x0800
- * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
+ * | 'version'=4, 'protocol'!=[1|6|17|50|132], 'MF'=0, 'frag_offset'=0>
* or,
* <'ether type'=0x86DD
- * | 'version'=6, 'next header'!=[6|17|44|132|1]>
+ * | 'version'=6, 'next header'!=[1|6|17|44|50|132]>
*/
#define RTE_PTYPE_INNER_L4_NONFRAG 0x06000000
+/**
+ * ESP (IP Encapsulating Security Payload) transport packet type.
+ * It is used for inner packet only.
+ *
+ * Packet format (inner only):
+ * <'ether type'=0x0800
+ * | 'version'=4, 'protocol'=50, 'MF'=0, 'frag_offset'=0>
+ * or,
+ * <'ether type'=0x86DD
+ * | 'version'=6, 'next header'=50>
+ */
+#define RTE_PTYPE_INNER_L4_ESP 0x08000000
/**
* Mask of inner layer 4 packet types.
*/
--
2.18.2
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-08-22 15:32 [PATCH] mbuf: add transport mode ESP packet type Alexander Kozyrev
@ 2024-09-02 8:43 ` Nithin Dabilpuram
2024-09-04 21:09 ` Alexander Kozyrev
0 siblings, 1 reply; 3+ messages in thread
From: Nithin Dabilpuram @ 2024-09-02 8:43 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: dev, dsosnowski, orika, olivier.matz, thomas, matan, jerinj,
rbhansali, ferruh.yigit
I think we already discussed this same patch in previous emails
(Aug-Oct 2023) at
https://mails.dpdk.org/archives/dev/2023-October/279390.html and
concluded that it is not needed ?
Did anything change from then ?
--
Nithin
On Thu, Aug 22, 2024 at 9:03 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> Support the IP Encapsulating Security Payload (ESP) in transport mode.
> Currently, we have RTE_PTYPE_TUNNEL_ESP for the ESP tunnel mode.
> Transport mode can be detected by parsing the "Next Header" field.
> The Next Header is TCP for the transport mode and IP for the tunnel mode.
> Add RTE_PTYPE_L4_ESP for the regular transport mode and
> RTE_PTYPE_INNER_L4_ESP for the ESP over UDP packets.
>
> Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> ---
> lib/mbuf/rte_mbuf_ptype.c | 2 ++
> lib/mbuf/rte_mbuf_ptype.h | 36 ++++++++++++++++++++++++++++++------
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/lib/mbuf/rte_mbuf_ptype.c b/lib/mbuf/rte_mbuf_ptype.c
> index d6f906b06c..ab180b3dda 100644
> --- a/lib/mbuf/rte_mbuf_ptype.c
> +++ b/lib/mbuf/rte_mbuf_ptype.c
> @@ -50,6 +50,7 @@ const char *rte_get_ptype_l4_name(uint32_t ptype)
> case RTE_PTYPE_L4_ICMP: return "L4_ICMP";
> case RTE_PTYPE_L4_NONFRAG: return "L4_NONFRAG";
> case RTE_PTYPE_L4_IGMP: return "L4_IGMP";
> + case RTE_PTYPE_L4_ESP: return "L4_ESP";
> default: return "L4_UNKNOWN";
> }
> }
> @@ -112,6 +113,7 @@ const char *rte_get_ptype_inner_l4_name(uint32_t ptype)
> case RTE_PTYPE_INNER_L4_SCTP: return "INNER_L4_SCTP";
> case RTE_PTYPE_INNER_L4_ICMP: return "INNER_L4_ICMP";
> case RTE_PTYPE_INNER_L4_NONFRAG: return "INNER_L4_NONFRAG";
> + case RTE_PTYPE_INNER_L4_ESP: return "INNER_L4_ESP";
> default: return "INNER_L4_UNKNOWN";
> }
> }
> diff --git a/lib/mbuf/rte_mbuf_ptype.h b/lib/mbuf/rte_mbuf_ptype.h
> index f2276e2909..c46a94f89f 100644
> --- a/lib/mbuf/rte_mbuf_ptype.h
> +++ b/lib/mbuf/rte_mbuf_ptype.h
> @@ -247,7 +247,7 @@ extern "C" {
> * It refers to those packets of any IP types, which can be recognized as
> * fragmented. A fragmented packet cannot be recognized as any other L4 types
> * (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP,
> - * RTE_PTYPE_L4_NONFRAG).
> + * RTE_PTYPE_L4_NONFRAG, RTE_PTYPE_L4_IGMP, RTE_PTYPE_L4_ESP).
> *
> * Packet format:
> * <'ether type'=0x0800
> @@ -290,14 +290,15 @@ extern "C" {
> *
> * It refers to those packets of any IP types, while cannot be recognized as
> * any of above L4 types (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP,
> - * RTE_PTYPE_L4_FRAG, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP).
> + * RTE_PTYPE_L4_FRAG (for IPv6), RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP,
> + * RTE_PTYPE_L4_IGMP (for IPv4), RTE_PTYPE_L4_ESP).
> *
> * Packet format:
> * <'ether type'=0x0800
> - * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
> + * | 'version'=4, 'protocol'!=[1|2|6|17|50|132], 'MF'=0, 'frag_offset'=0>
> * or,
> * <'ether type'=0x86DD
> - * | 'version'=6, 'next header'!=[6|17|44|132|1]>
> + * | 'version'=6, 'next header'!=[1|6|17|44|50|132]>
> */
> #define RTE_PTYPE_L4_NONFRAG 0x00000600
> /**
> @@ -308,6 +309,17 @@ extern "C" {
> * | 'version'=4, 'protocol'=2, 'MF'=0, 'frag_offset'=0>
> */
> #define RTE_PTYPE_L4_IGMP 0x00000700
> +/**
> + * ESP (IP Encapsulating Security Payload) transport packet type.
> + *
> + * Packet format:
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=50, 'MF'=0, 'frag_offset'=0>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=50>
> + */
> +#define RTE_PTYPE_L4_ESP 0x00000800
> /**
> * Mask of layer 4 packet types.
> * It is used for outer packet for tunneling cases.
> @@ -652,12 +664,24 @@ extern "C" {
> *
> * Packet format (inner only):
> * <'ether type'=0x0800
> - * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
> + * | 'version'=4, 'protocol'!=[1|6|17|50|132], 'MF'=0, 'frag_offset'=0>
> * or,
> * <'ether type'=0x86DD
> - * | 'version'=6, 'next header'!=[6|17|44|132|1]>
> + * | 'version'=6, 'next header'!=[1|6|17|44|50|132]>
> */
> #define RTE_PTYPE_INNER_L4_NONFRAG 0x06000000
> +/**
> + * ESP (IP Encapsulating Security Payload) transport packet type.
> + * It is used for inner packet only.
> + *
> + * Packet format (inner only):
> + * <'ether type'=0x0800
> + * | 'version'=4, 'protocol'=50, 'MF'=0, 'frag_offset'=0>
> + * or,
> + * <'ether type'=0x86DD
> + * | 'version'=6, 'next header'=50>
> + */
> +#define RTE_PTYPE_INNER_L4_ESP 0x08000000
> /**
> * Mask of inner layer 4 packet types.
> */
> --
> 2.18.2
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-09-02 8:43 ` Nithin Dabilpuram
@ 2024-09-04 21:09 ` Alexander Kozyrev
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Kozyrev @ 2024-09-04 21:09 UTC (permalink / raw)
To: Nithin Dabilpuram
Cc: dev, Dariusz Sosnowski, Ori Kam, olivier.matz,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
> I think we already discussed this same patch in previous emails
> (Aug-Oct 2023) at
> https://mails.dpdk.org/archives/dev/2023-October/279390.html and
> concluded that it is not needed ?
> Did anything change from then ?
Yes, Nithin, we found a way to distinguish the modes by looking into the next header field.
And we definitely need RTE_PTYPE_INNER_L4_ESP for ESP over UDP support.
Having RTE_PTYPE_INNER_TUNNEL_ESP for this case doesn't make sense,
and, I think, it is better to introduce two L4 types for ESP now. What are your thoughts on this?
[-- Attachment #2: Type: text/html, Size: 2093 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-09-04 21:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-22 15:32 [PATCH] mbuf: add transport mode ESP packet type Alexander Kozyrev
2024-09-02 8:43 ` Nithin Dabilpuram
2024-09-04 21:09 ` Alexander Kozyrev
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).