ontact-Thomas
> > Monjalon (EXTERNAL) ; Matan Azrad
> > ; jer...@marvell.com; rbhans...@marvell.com;
> > ferruh.yi...@amd.com
> > Subject: [PATCH] mbuf: add transport mode ESP packet type
> >
> > Support the IP Encapsulating Security Payload (ESP) in transport m
On Tue, Oct 29, 2024 at 7:48 AM Ori Kam wrote:
>
> Hi Ajit, Nithin and Olivier
>
> > -Original Message-
> > From: Ajit Khaparde
> > Sent: Friday, October 25, 2024 2:33 AM
> >
> > On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev
> > wrote:
> > >
> > > >>And we definitely need RTE_PTYPE_
Hi Ajit, Nithin and Olivier
> -Original Message-
> From: Ajit Khaparde
> Sent: Friday, October 25, 2024 2:33 AM
>
> On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev
> wrote:
> >
> > >>And we definitely need RTE_PTYPE_INNER_L4_ESP for ESP over UDP
> support.
> > >Isn't this already tak
On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev 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
>>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 the
>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 wrote:
>
> > I am curious, where is the driver that implements this?
> I'll
> I am curious, where is the driver that implements this?
I'll send MLX5 implementation shortly.
On Thu, Aug 22, 2024 at 5:33 PM Alexander Kozyrev 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 t
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 Hea
r...@marvell.com; rbhans...@marvell.com;
> ferruh.yi...@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 d
> 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 ne
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 wrote:
>
> Support the
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 f
13 matches
Mail list logo
