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