[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALx6S36SRug4WyGTpc65eVEt7XWPe+_1pbRAQu7CjtxckwbBVA@mail.gmail.com>
Date: Tue, 20 Aug 2024 12:00:30 -0700
From: Tom Herbert <tom@...bertland.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
felipe@...anda.io, willemdebruijn.kernel@...il.com
Subject: Re: [PATCH net-next v2 04/12] flow_dissector: UDP encap infrastructure
On Tue, Aug 20, 2024 at 11:52 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Aug 15, 2024 at 11:46 PM Tom Herbert <tom@...bertland.com> wrote:
> >
> > Add infrastructure for parsing into UDP encapsulations
> >
> > Add function __skb_flow_dissect_udp that is called for IPPROTO_UDP.
> > The flag FLOW_DISSECTOR_F_PARSE_UDP_ENCAPS enables parsing of UDP
> > encapsulations. If the flag is set when parsing a UDP packet then
> > a socket lookup is performed. The offset of the base network header,
> > either an IPv4 or IPv6 header, is tracked and passed to
> > __skb_flow_dissect_udp so that it can perform the socket lookup
> >
> > If a socket is found and it's for a UDP encapsulation (encap_type is
> > set in the UDP socket) then a switch is performed on the encap_type
> > value (cases are UDP_ENCAP_* values)
> >
> > An encapsulated packet in UDP can either be indicated by an
> > EtherType or IP protocol. The processing for dissecting a UDP encap
> > protocol returns a flow dissector return code. If
> > FLOW_DISSECT_RET_PROTO_AGAIN or FLOW_DISSECT_RET_IPPROTO_AGAIN is
> > returned then the corresponding encapsulated protocol is dissected.
> > The nhoff is set to point to the header to process. In the case
> > FLOW_DISSECT_RET_PROTO_AGAIN the EtherType protocol is returned and
> > the IP protocol is set to zero. In the case of
> > FLOW_DISSECT_RET_IPPROTO_AGAIN, the IP protocol is returned and
> > the EtherType protocol is returned unchanged
> >
> > Signed-off-by: Tom Herbert <tom@...bertland.com>
>
> I am a bit confused.
>
> How is this series netns ready ?
>
> tunnel decap devices can be in different netns from the lower device.
>
> socket lookups need the correct net pointer.
Hi Eric,
How would we know what the correct net pointer is? Seems like there
could be multiple choices if netns were nested. Maybe best effort is
sufficient here?
Tom
Powered by blists - more mailing lists