[Feat] Support UPF without 'gtp5g' module

[iancoolidge]

There is pushback against upstreaming the 'gtp5g' module: https://lore.kernel.org/netdev/Yio5%2F+Ko77tu4Vi6@nataraja/T/#m888eb5eb3266987f326ed9ab4996a57bb23d5012

It is sometimes difficult to get an out of tree module applied to any platform (for example, sometimes platforms require signed modules)

free5gc should consider gracefully handling the absence of 'gtp5g' module

[brianchennn]

@iancoolidge No, free5gc should bind to gtp5g with correct version. If you use the different module, free5gc won't run properly in user space.

If you want to try the different module, you can simply comment out the code in free5gc/upf/internal/forwarder/gtp5g.go line 98, and observe what will happen.

err = g.checkVersion()
    if err != nil {
        g.Close()
        return nil, errors.Wrap(err, "version mismatch")
    }

[iancoolidge]

I'm not talking about a different module, I'm talking about "no" module.

Why not just have a userspace implementation to fall back to?

To me, it feels like if upstream is against the idea of these protocols being implemented in the kernel, it's also a good argument for not doing them in kernel space at all.

[brianchennn]

@iancoolidge Module gtp5g is utilized in UPF (User Plane Function). UPF is in charge of data forwarding in data plane. It will create GTP tunnel when the PDU Session is established. It's faster to be processed in kernel space. If you don't install this kernel module, the UPF can't run.

[ianchen0119]

Hi @iancoolidge

Why not just have a userspace implementation to fall back to?

This solution can resolve the upstream issue definitely. But Implement UPF (data plane) in the kernel space brings more efficiency on the data processing.

Actually, most of Open-Source UPF implementations were kernel based application (e.g. XDP, Kernel Module). Consider to the upstream issue, our documentation has listed the required environments for preventing this kind of problem.

Thanks.