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

[Harald Welte <laforge@gnumonks.org>]

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)