On Tue, Oct 29, 2024 at 7:48 AM Ori Kam <or...@nvidia.com> wrote: > > Hi Ajit, Nithin and Olivier > > > -----Original Message----- > > From: Ajit Khaparde <ajit.khapa...@broadcom.com> > > Sent: Friday, October 25, 2024 2:33 AM > > > > On Thu, Oct 24, 2024 at 12:30 PM Alexander Kozyrev <akozy...@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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
