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
Hi Anil,
On Fri, Oct 02, 2026 at 01:40:02PM +0000, Anil Kaushik wrote:
- 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.
- 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:
The shape of the RX patch depends on this, so I'd rather ask than guess.
- 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.
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
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:
- 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.
- 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:
The shape of the RX patch depends on this, so I'd rather ask than guess.
- 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.
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)
osmocom-net-gprs@lists.osmocom.org
-
Anil Kaushik -
Harald Welte