diff mbox series

mbuf: add transport mode ESP packet type

Message ID 20240822153218.3782170-1-akozyrev@nvidia.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series mbuf: add transport mode ESP packet type |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/github-robot: build success github build: passed
ci/intel-Functional success Functional PASS
ci/iol-marvell-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS

Commit Message

Alexander Kozyrev Aug. 22, 2024, 3:32 p.m. UTC 
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(-)

Comments

Nithin Dabilpuram Sept. 2, 2024, 8:43 a.m. UTC | #1 
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
>
Alexander Kozyrev Sept. 4, 2024, 9:09 p.m. UTC | #2 
> 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?
Dariusz Sosnowski Oct. 15, 2024, 2:40 p.m. UTC | #3 
> -----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
Thomas Monjalon Oct. 17, 2024, 8:47 p.m. UTC | #4 
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.
>   */
>
David Marchand Oct. 18, 2024, 1:44 p.m. UTC | #5 
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?
Alexander Kozyrev Oct. 22, 2024, 1:19 p.m. UTC | #6 
> I am curious, where is the driver that implements this?
I'll send MLX5 implementation shortly.
Nithin Dabilpuram Oct. 23, 2024, 4:54 a.m. UTC | #7 
>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.
Alexander Kozyrev Oct. 24, 2024, 7:30 p.m. UTC | #8 
>>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.
Ajit Khaparde Oct. 24, 2024, 11:32 p.m. UTC | #9 
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.

>
Ori Kam Oct. 29, 2024, 2:48 p.m. UTC | #10 
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
Ajit Khaparde Oct. 29, 2024, 6:41 p.m. UTC | #11 
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
>
>
Thomas Monjalon Nov. 9, 2024, 11:50 a.m. UTC | #12 
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.
diff mbox series

Patch

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.
  */