* 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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-11-09 11:50 ` Thomas Monjalon
2024-10-17 20:47 ` Thomas Monjalon
2024-10-18 13:44 ` David Marchand
3 siblings, 1 reply; 13+ 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] 13+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-15 14:40 ` Dariusz Sosnowski
@ 2024-11-09 11:50 ` Thomas Monjalon
0 siblings, 0 replies; 13+ messages in thread
From: Thomas Monjalon @ 2024-11-09 11:50 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: dev, Ori Kam, nithind1988, olivier.matz, Matan Azrad, jerinj,
rbhansali, ferruh.yigit, Dariusz Sosnowski
15/10/2024 16:40, Dariusz Sosnowski:
> > -----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>
Applied, thanks.
^ permalink raw reply [flat|nested] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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
2024-10-24 19:30 ` Alexander Kozyrev
0 siblings, 1 reply; 13+ 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] 13+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-23 4:54 ` Nithin Dabilpuram
@ 2024-10-24 19:30 ` Alexander Kozyrev
2024-10-24 23:32 ` Ajit Khaparde
0 siblings, 1 reply; 13+ messages in thread
From: Alexander Kozyrev @ 2024-10-24 19:30 UTC (permalink / raw)
To: Nithin Dabilpuram
Cc: David Marchand, dev, Dariusz Sosnowski, Ori Kam, olivier.matz,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
>>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) ?
This is ambigous. And both UDP and ESP are L4 headers,
which can lead to the undefined behavior when we specify both of them.
They are mutually exclusive in our hardware, for example.
That is why we have RTE_PTYPE_TUNNEL_MPLS_IN_GRE and
RTE_PTYPE_TUNNEL_MPLS_IN_UDP for MPLS.
We could go and indroduce RTE_PTYPE_TUNNEL_ESP_IN_UDP
to resolve the ambiguity, or have RTE_PTYPE_INNER_L4_ESP.
I choose the second variant to have a generic way for
ESP packets over any type of encapsulation.
[-- Attachment #2: Type: text/html, Size: 2948 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-24 19:30 ` Alexander Kozyrev
@ 2024-10-24 23:32 ` Ajit Khaparde
2024-10-29 14:48 ` Ori Kam
0 siblings, 1 reply; 13+ messages in thread
From: Ajit Khaparde @ 2024-10-24 23:32 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: Nithin Dabilpuram, David Marchand, dev, Dariusz Sosnowski,
Ori Kam, olivier.matz, NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> >>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) ?
>
> This is ambigous. And both UDP and ESP are L4 headers,
> which can lead to the undefined behavior when we specify both of them.
> They are mutually exclusive in our hardware, for example.
> That is why we have RTE_PTYPE_TUNNEL_MPLS_IN_GRE and
> RTE_PTYPE_TUNNEL_MPLS_IN_UDP for MPLS.
> We could go and indroduce RTE_PTYPE_TUNNEL_ESP_IN_UDP
> to resolve the ambiguity, or have RTE_PTYPE_INNER_L4_ESP.
> I choose the second variant to have a generic way for
> ESP packets over any type of encapsulation.
The choice sounds reasonable to me.
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4218 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH] mbuf: add transport mode ESP packet type
2024-10-24 23:32 ` Ajit Khaparde
@ 2024-10-29 14:48 ` Ori Kam
2024-10-29 18:41 ` Ajit Khaparde
0 siblings, 1 reply; 13+ messages in thread
From: Ori Kam @ 2024-10-29 14:48 UTC (permalink / raw)
To: Ajit Khaparde, Alexander Kozyrev, olivier.matz, Nithin Dabilpuram
Cc: David Marchand, dev, Dariusz Sosnowski,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
Hi Ajit, Nithin and Olivier
> -----Original Message-----
> From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Sent: Friday, October 25, 2024 2:33 AM
>
> On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev <akozyrev@nvidia.com>
> wrote:
> >
> > >>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) ?
> >
> > This is ambigous. And both UDP and ESP are L4 headers,
> > which can lead to the undefined behavior when we specify both of them.
> > They are mutually exclusive in our hardware, for example.
> > That is why we have RTE_PTYPE_TUNNEL_MPLS_IN_GRE and
> > RTE_PTYPE_TUNNEL_MPLS_IN_UDP for MPLS.
> > We could go and indroduce RTE_PTYPE_TUNNEL_ESP_IN_UDP
> > to resolve the ambiguity, or have RTE_PTYPE_INNER_L4_ESP.
> > I choose the second variant to have a generic way for
> > ESP packets over any type of encapsulation.
> The choice sounds reasonable to me.
>
> >
Let's understand the issue.
We have 3 possible options for the ESP:
1. as L4 outer, in this case, the ESP replaces the UDP/TCP protocol
2. as L4 inner, in this case, the ESP replaces the UDP/TCP inner protocol.
3. the ESP comes after UDP and is considered a tunnel.
As far as I see the request is to give the application the ability to know what is the packet type, so
Alexander's original patch fully fulfills this requirement. What am I missing?
Do you have a different suggestion that matches the requirement?
Best,
Ori
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] mbuf: add transport mode ESP packet type
2024-10-29 14:48 ` Ori Kam
@ 2024-10-29 18:41 ` Ajit Khaparde
0 siblings, 0 replies; 13+ messages in thread
From: Ajit Khaparde @ 2024-10-29 18:41 UTC (permalink / raw)
To: Ori Kam
Cc: Alexander Kozyrev, olivier.matz, Nithin Dabilpuram,
David Marchand, dev, Dariusz Sosnowski,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Matan Azrad, jerinj, rbhansali, ferruh.yigit
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On Tue, Oct 29, 2024 at 7:48 AM Ori Kam <orika@nvidia.com> wrote:
>
> Hi Ajit, Nithin and Olivier
>
> > -----Original Message-----
> > From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > Sent: Friday, October 25, 2024 2:33 AM
> >
> > On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev <akozyrev@nvidia.com>
> > wrote:
> > >
> > > >>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) ?
> > >
> > > This is ambigous. And both UDP and ESP are L4 headers,
> > > which can lead to the undefined behavior when we specify both of them.
> > > They are mutually exclusive in our hardware, for example.
> > > That is why we have RTE_PTYPE_TUNNEL_MPLS_IN_GRE and
> > > RTE_PTYPE_TUNNEL_MPLS_IN_UDP for MPLS.
> > > We could go and indroduce RTE_PTYPE_TUNNEL_ESP_IN_UDP
> > > to resolve the ambiguity, or have RTE_PTYPE_INNER_L4_ESP.
> > > I choose the second variant to have a generic way for
> > > ESP packets over any type of encapsulation.
> > The choice sounds reasonable to me.
> >
> > >
>
> Let's understand the issue.
> We have 3 possible options for the ESP:
> 1. as L4 outer, in this case, the ESP replaces the UDP/TCP protocol
> 2. as L4 inner, in this case, the ESP replaces the UDP/TCP inner protocol.
> 3. the ESP comes after UDP and is considered a tunnel.
>
> As far as I see the request is to give the application the ability to know what is the packet type, so
> Alexander's original patch fully fulfills this requirement. What am I missing?
> Do you have a different suggestion that matches the requirement?
I was indicating that RTE_PTYPE_INNER_L4_ESP was a better approach.
Just document the usage on how it can be used and I feel we should be ok.
>
> Best,
> Ori
>
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4218 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread