Chapter 14: Data-Plane Changes — db-mux + MSET

Change 1: Replace db-proxy with db-mux

All DB operations in the PFCP session handling path switch from db-proxy to db-mux. This alone gives ~2.5× CPU reduction for DB operations.

Change 2: Batch Related Writes with MSET

// BEFORE (do_store_set in upf_session_ctrl):
db_proxy_set("teid:1234", teid_data, cb1);  // individual SET
db_proxy_set("ueip:5678", ueip_data, cb2);  // individual SET
db_proxy_set("l2tp:9012", l2tp_data, cb3);  // individual SET
pending_ops = 3;  // wait for all 3 callbacks

// AFTER (using db-mux multicommand API):
mux_multi_t *m = mux_multi_start(mux);
mux_multi_add(m, "{sess:X}:teid", teid_data);
mux_multi_add(m, "{sess:X}:ueip", ueip_data);
mux_multi_add(m, "{sess:X}:l2tp", l2tp_data);
mux_multi_exec_mset(m, single_callback);  // ONE MSET, ONE callback

Test Results (from PoC)

• Throughput mode + db-mux + MSET: tested on CeeB latency jitter TC
• Low latency mode + db-mux + MSET: tested
• Low latency mode + db-mux (no MSET): tested

Follow-up: need to test on spare thread (current PoC may be on control thread).

Open Question: Is db-mux Worth It for Latency?

db-mux has higher per-command RTT than db-proxy async. The question from today's meeting: should we use db-mux purely for CPU savings (even if latency is slightly worse), or is there a way to get both?

Possible answer: time-based batching in db-mux could improve throughput further while accepting slightly higher latency.

Mark as Complete