[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S34ei7r47XvhCHVaMZuw4-iCALZ9MDytpNN=syd9kuv05Q@mail.gmail.com>
Date: Thu, 15 Aug 2024 11:52:11 -0700
From: Tom Herbert <tom@...bertland.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, edumazet@...gle.com,
netdev@...r.kernel.org, felipe@...anda.io
Subject: Re: [PATCH 04/12] udp_encaps: Add new UDP_ENCAP constants
On Thu, Aug 1, 2024 at 6:22 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Tom Herbert wrote:
> > Add constants for various UDP encapsulations that are supported
> >
> > Signed-off-by: Tom Herbert <tom@...bertland.com>
> > ---
> > include/uapi/linux/udp.h | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
> > index 1a0fe8b151fb..0432a9a6536d 100644
> > --- a/include/uapi/linux/udp.h
> > +++ b/include/uapi/linux/udp.h
> > @@ -36,6 +36,7 @@ struct udphdr {
> > #define UDP_GRO 104 /* This socket can receive UDP GRO packets */
> >
> > /* UDP encapsulation types */
> > +#define UDP_ENCAP_NONE 0
> > #define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* unused draft-ietf-ipsec-nat-t-ike-00/01 */
> > #define UDP_ENCAP_ESPINUDP 2 /* draft-ietf-ipsec-udp-encaps-06 */
> > #define UDP_ENCAP_L2TPINUDP 3 /* rfc2661 */
> > @@ -43,5 +44,17 @@ struct udphdr {
> > #define UDP_ENCAP_GTP1U 5 /* 3GPP TS 29.060 */
> > #define UDP_ENCAP_RXRPC 6
> > #define TCP_ENCAP_ESPINTCP 7 /* Yikes, this is really xfrm encap types. */
> > +#define UDP_ENCAP_TIPC 8
> > +#define UDP_ENCAP_FOU 9
> > +#define UDP_ENCAP_GUE 10
> > +#define UDP_ENCAP_SCTP 11
> > +#define UDP_ENCAP_RXE 12
> > +#define UDP_ENCAP_PFCP 13
> > +#define UDP_ENCAP_WIREGUARD 14
> > +#define UDP_ENCAP_BAREUDP 15
> > +#define UDP_ENCAP_VXLAN 16
> > +#define UDP_ENCAP_VXLAN_GPE 17
> > +#define UDP_ENCAP_GENEVE 18
> > +#define UDP_ENCAP_AMT 19
>
> Should these existing constants never have been UAPI to begin with?
Hi Willem,
I'm inclined to think they probably should be, especially if we need
these in eBPF.
Tom
>
Powered by blists - more mailing lists