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? Best, Ori
