* 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
2024-10-15 14:40 ` Dariusz Sosnowski
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ 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] 8+ 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; 8+ 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] 8+ 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-10-15 14:40 ` Dariusz Sosnowski
2024-10-17 20:47 ` Thomas Monjalon
2024-10-18 13:44 ` David Marchand
3 siblings, 0 replies; 8+ messages in thread
From: Dariusz Sosnowski @ 2024-10-15 14:40 UTC (permalink / raw)
To: Alexander Kozyrev, dev
Cc: Ori Kam, nithind1988, olivier.matz,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
> -----Original Message-----
> From: Alexander Kozyrev <akozyrev@nvidia.com>
> Sent: Thursday, August 22, 2024 17:32
> To: dev@dpdk.org
> Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>; Ori Kam <orika@nvidia.com>;
> nithind1988@gmail.com; olivier.matz@6wind.com; NBU-Contact-Thomas
> Monjalon (EXTERNAL) <thomas@monjalon.net>; Matan Azrad
> <matan@nvidia.com>; jerinj@marvell.com; rbhansali@marvell.com;
> ferruh.yigit@amd.com
> Subject: [PATCH] mbuf: add transport mode ESP packet type
>
> 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>
Reviewed-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Best regards,
Dariusz Sosnowski
^ permalink raw reply [flat|nested] 8+ 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-10-15 14:40 ` Dariusz Sosnowski
@ 2024-10-17 20:47 ` Thomas Monjalon
2024-10-18 13:44 ` David Marchand
3 siblings, 0 replies; 8+ messages in thread
From: Thomas Monjalon @ 2024-10-17 20:47 UTC (permalink / raw)
To: dev
Cc: dsosnowski, orika, nithind1988, olivier.matz, matan, jerinj,
rbhansali, ferruh.yigit, Alexander Kozyrev, Akhil, Goyal,
Anoob Joseph
Please could we have another review?
22/08/2024 17:32, Alexander Kozyrev:
> 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.
> */
>
^ permalink raw reply [flat|nested] 8+ 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
` (2 preceding siblings ...)
2024-10-17 20:47 ` Thomas Monjalon
@ 2024-10-18 13:44 ` David Marchand
2024-10-22 13:19 ` Alexander Kozyrev
3 siblings, 1 reply; 8+ messages in thread
From: David Marchand @ 2024-10-18 13:44 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: dev, dsosnowski, orika, nithind1988, olivier.matz, thomas, matan,
jerinj, rbhansali, ferruh.yigit
On Thu, Aug 22, 2024 at 5:33 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>
I am curious, where is the driver that implements this?
--
David Marchand
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-18 13:44 ` David Marchand
@ 2024-10-22 13:19 ` Alexander Kozyrev
2024-10-23 4:54 ` Nithin Dabilpuram
0 siblings, 1 reply; 8+ messages in thread
From: Alexander Kozyrev @ 2024-10-22 13:19 UTC (permalink / raw)
To: David Marchand
Cc: dev, Dariusz Sosnowski, Ori Kam, nithind1988, olivier.matz,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
> I am curious, where is the driver that implements this?
I'll send MLX5 implementation shortly.
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-22 13:19 ` Alexander Kozyrev
@ 2024-10-23 4:54 ` Nithin Dabilpuram
0 siblings, 0 replies; 8+ messages in thread
From: Nithin Dabilpuram @ 2024-10-23 4:54 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: David Marchand, dev, Dariusz Sosnowski, Ori Kam, olivier.matz,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
>And we definitely need RTE_PTYPE_INNER_L4_ESP for ESP over UDP support.
Isn't this already taken care when mbuf->packet_type =
(RTE_PTYPE_L4_UDP | RTE_PTYPE_TUNNEL_ESP) ?
On Tue, Oct 22, 2024 at 6:49 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> > I am curious, where is the driver that implements this?
> I'll send MLX5 implementation shortly.
^ permalink raw reply [flat|nested] 8+ messages in thread