Thread (3 messages) 3 messages, 2 authors, 1d ago

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

From: Anil Kaushik <hidden>
Date: 2026-10-02 13:40:11

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help