15/10/2024 16:40, Dariusz Sosnowski:
> > -Original Message-
> > From: Alexander Kozyrev
> > Sent: Thursday, August 22, 2024 17:32
> > To: dev@dpdk.org
> > Cc: Dariusz Sosnowski ; Ori Kam ;
> > nithind1...@gmail.com; olivier.m...@6wind.com; NBU-Contact-Thomas
> > Monjalon (EXTERNAL) ; Matan
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
> -Original Message-
> From: Alexander Kozyrev
> Sent: Thursday, August 22, 2024 17:32
> To: dev@dpdk.org
> Cc: Dariusz Sosnowski ; Ori Kam ;
> nithind1...@gmail.com; olivier.m...@6wind.com; NBU-Contact-Thomas
> Monjalon (EXTERNAL) ; Matan Azrad
> ; jer...@marvell.com; rbhans...@marvell.co
> 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
12 matches
Mail list logo
