如果覺得文章對你有所啟發，可以考慮用 🌟 支持 Gthulhu 專案，短期目標是集齊 300 個 🌟 藉此被 CNCF Landscape 採納 [ref]。

5G 核心網路將所有的 Data-Plane traffic 都交給 UPF 網路元件處理。在 free5GC 中，我們又再將 UPF 分成兩個部分實作：

• application：負責處理 N4 介面的控制訊號，將訊號轉為封包處理規則送往 kernel space。
• kernel module：實作一個 virtual network device，將封包處理的所有任務保留在 kernel space 來提高吞吐量。

結合我們先前的研究成果，要整合 free5GC 的困難度在於：

• Linux kernel 的網路堆疊很複雜
• 如果使用 kubernetes 部署 free5GC，我們要考慮 data-plane traffic 的流向（來自同節點還是跨節點、送往同節點還是跨節點？）

這些因素會導致我們無法直接告訴 API server 只要降低 UPF process 的 latency 即可，因為 kernel module 在處理封包時並不是使用 UPF process 的 context。

為了有效的識別出那個 destiny（誰接收了封包、又是誰把封包送出去），我們就需要想辦法觀察 kernel module（gtp5g）的行為。
而 eBPF 本身就是 observability 的利器，所以我利用 BTF export 出 gtp5g 中的 self-defined structure，並且觀察有哪些函式能夠被 ftrace 觀測到。抓出 gtp5g 之中明確的 uplink 與 downlink 進入點，我就能用 eBPF 進行觀測了：）

• 程式碼可參考 gtp5g-tracer
• 當初實作 gtp5g-tracer 撰寫的文章：https://free5gc.org/blog/20241224/
• 更 detail 的文章：https://free5gc.org/blog/20250913/20250913/

我在這邊先總結一下觀察到的結果：

• Uplink 會綁著收進封包的 context，比如說，N3 的封包從某個網卡收進來，那麼 Uplink 會由那張網卡的 irq 處理。經過處理後送往 N6 則是看 N6 對應的是哪張網卡，會有對應的 irq 處理。
• Downlinkk 同樣看綁著收進封包的 context，比如說，N6 的封包從某個網卡收進來，那麼就由這張網卡的 irq 處理。
• 如果所有的通訊都在一個 node 裡面（UERANSIM, DN server 都在同一個機器上），那麼就會吃到 nr-ue（因為用來測試的 ICMP 是由 nr-ue 送出的）這個 process 的 context。