[RFC] gtp: add 5G PDU Session Container (QFI) support?

[RFC] gtp: add 5G PDU Session Container (QFI) support?

[Anil Kaushik]

Hi Pablo, Harald,

The in-tree GTP driver supports GTPv0 and GTPv1-U, but has no handling
for the 5G N3 PDU Session Container (PSC) extension header (type 0x85,
3GPP TS 29.281 / TS 38.415) that carries the QoS Flow Identifier (QFI).
drivers/net/gtp.c also still has the "TODO: Support for extension
header, sequence number and N-PDU" on the xmit path.

I'd like to add PSC/QFI support, but before writing the datapath code I
wanted to check two things with you.

1) Is this something you'd welcome in mainline gtp.c?  I'm aware a lot of
   5G user-plane work lives in out-of-tree datapaths (gtp5g, the eBPF
   eUPF), so I don't want to add datapath complexity you'd rather not
   carry here.

2) If yes: on RX, once the QFI has been parsed out of the PSC, what would
   you like the driver to do with it?  The options I see are:
     - stash it in skb->mark, so tc/nftables can classify uplink traffic
       by QoS flow;
     - attach it as skb metadata (tc_skb_ext / metadata_dst); or
     - just validate it and otherwise ignore it.
   The shape of the RX patch depends on this, so I'd rather ask than
   guess.

The plan would be a small incremental series:
  1. add a GTPA_QFI (u8) netlink attribute + ynl spec, stored per PDP
     context (control-plane plumbing only);
  2. RX: parse the PSC extension header and extract the QFI;
  3. TX: build the PSC from the per-PDP QFI on the downlink path (the
     existing extension-header TODO).

Patch 1 is already written and builds; I'll post the series once I know
whether you want it in mainline and how you'd prefer the RX QFI to be
surfaced.  Happy to adjust the approach.

Thanks,
Anil

Re: [RFC] gtp: add 5G PDU Session Container (QFI) support?

[Harald Welte]

Hi Anil,

On Fri, Oct 02, 2026 at 01:40:02PM +0000, Anil Kaushik wrote:
> 1) Is this something you'd welcome in mainline gtp.c?  I'm aware a lot of
>    5G user-plane work lives in out-of-tree datapaths (gtp5g, the eBPF
>    eUPF), so I don't want to add datapath complexity you'd rather not
>    carry here.

I think the big question is about the use case.  Do you yourself have a use case
for this? Which userspace programs (ideally open source ones) will be using your
proposed mechanism? For the existing GTPv0/v1 code we have a couple of different
FOSS applications (osmo-ggsn and ergw) as well as know of a number of proprietary
applications using it.

So I'm wondering if this proposed enhancement is "just for the sake of completeness",
or if you have any application (or will contribute patches to existing applications) so
they will make use of this feature.

> 2) If yes: on RX, once the QFI has been parsed out of the PSC, what would
>    you like the driver to do with it?  The options I see are:
>      - stash it in skb->mark, so tc/nftables can classify uplink traffic
>        by QoS flow;
>      - attach it as skb metadata (tc_skb_ext / metadata_dst); or
>      - just validate it and otherwise ignore it.
>    The shape of the RX patch depends on this, so I'd rather ask than
>    guess.

I would say skb->mark would make sense to me.

Regards,
	Harald

p.s.: Answers might be slow, I'm just about to go on a motorbike tour in remote
mountainous areas with limited connectivity and/or time for e-mails

-- 
- Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: [RFC] gtp: add 5G PDU Session Container (QFI) support?

[Anil Kaushik]

Hi Harald,

Thanks for the quick, clear feedback — and for the skb->mark steer.

On the use case: honestly, I don't have one that would drive this in
mainline. My own 5G user plane is Magma, which does GTP-U in OVS
(OpenFlow) — not via the kernel GTP driver / libgtpnl — so it wouldn't
be a consumer of a GTPA_QFI attribute. So at this moment it will
remain futuristic and for completeness.

Separately, I sent a small patch that stands on its own, independent of
QFI — a ynl (genetlink-legacy) spec for the existing gtp family:

  [RFC net-next] netlink: specs: add genetlink-legacy spec for GTP
  (netdev, 2026-10-01)

It just describes the current NEWPDP/DELPDP/GETPDP/ECHOREQ family so it
can be used with the ynl tooling/docs — no datapath or uapi change. If
that's useful I'm happy to respin it as a proper [PATCH net-next];
feedback welcome.

No rush at all — enjoy the ride, and safe travels.

Thanks again,
Anil


On Sat, Oct 3, 2026 at 11:28 AM Harald Welte <laforge@gnumonks.org> wrote:
>
> Hi Anil,
>
> On Fri, Oct 02, 2026 at 01:40:02PM +0000, Anil Kaushik wrote:
> > 1) Is this something you'd welcome in mainline gtp.c?  I'm aware a lot of
> >    5G user-plane work lives in out-of-tree datapaths (gtp5g, the eBPF
> >    eUPF), so I don't want to add datapath complexity you'd rather not
> >    carry here.
>
> I think the big question is about the use case.  Do you yourself have a use case
> for this? Which userspace programs (ideally open source ones) will be using your
> proposed mechanism? For the existing GTPv0/v1 code we have a couple of different
> FOSS applications (osmo-ggsn and ergw) as well as know of a number of proprietary
> applications using it.
>
> So I'm wondering if this proposed enhancement is "just for the sake of completeness",
> or if you have any application (or will contribute patches to existing applications) so
> they will make use of this feature.
>
> > 2) If yes: on RX, once the QFI has been parsed out of the PSC, what would
> >    you like the driver to do with it?  The options I see are:
> >      - stash it in skb->mark, so tc/nftables can classify uplink traffic
> >        by QoS flow;
> >      - attach it as skb metadata (tc_skb_ext / metadata_dst); or
> >      - just validate it and otherwise ignore it.
> >    The shape of the RX patch depends on this, so I'd rather ask than
> >    guess.
>
> I would say skb->mark would make sense to me.
>
> Regards,
>         Harald
>
> p.s.: Answers might be slow, I'm just about to go on a motorbike tour in remote
> mountainous areas with limited connectivity and/or time for e-mails
>
> --
> - Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)