Chapter 7: PFCP Session Flow — What Happens When a Session is Created
End-to-End Flow: Session Establishment
SMF PEP DP Valkey
│ │ │ │
│──PFCP Establish──► │ │ │
│ │ │ │
│ │──SET session blob──────────────────────────────► │
│ │◄─────────────────────────────────────────── OK── │
│ │ │ │
│ │──mbox: install rules──► │ │
│ │ │ │
│ │ │──SET teid:1234────────►│
│ │ │──SET ueip:5678────────►│
│ │ │──SET l2tp:9012────────►│
│ │ │◄──────────── OK OK OK──│
│ │ │ │
│ │◄──mbox: done────────────│ │
│ │ │ │
│◄─PFCP Establish Rsp─│ │ │
│ │ │ │
The 3 SET commands in DP are what PCPB-25616 batches into 1 MSET.
DP's do_store_set() — The Batching Target
In data-plane, upf_session_ctrl_do_store() handles DB writes during session establishment/modification/deletion:
// Simplified flow in data-plane (upf/src/):
void do_store_set(session_ctx *ctx) {
// Enqueue multiple DB operations:
db_write("teid:{session_id}", teid_data); // op 1
db_write("ueip:{session_id}", ueip_data); // op 2
db_write("l2tp:{session_id}", l2tp_data); // op 3
// ... more depending on session type
ctx->pending_ops = N; // count pending
// Each reply decrements pending_ops
// When pending_ops == 0 → state machine advances
}
// CURRENT: N individual SET commands (pipelined via EVL batching)
// NEW: 1 MSET command with all keys (explicit batching)
Why MSET is Better Than Pipelined SETs
| Aspect | Pipelined SETs | MSET |
|---|---|---|
| Redis commands parsed | N | 1 |
| Redis replies generated | N | 1 |
| Callback overhead in app | N callbacks | 1 callback |
| Bookkeeping (pending counter) | Yes (complex) | No (single op) |
| Atomicity | No (partial failure possible) | Yes (all-or-nothing) |
| Code clarity | Scattered writes | Explicit "these are related" |
Session Modification and Deletion
Same pattern applies:
- Modification: update some keys (MSET for changed keys)
- Deletion: remove all keys (DEL or UNLINK for multiple keys)
Latency Breakdown
PFCP Establishment end-to-end latency:
┌──────────────────────────────────────────────────────────┐
│ PEP parse │ PEP DB │ mbox │ DP logic │ DP DB │ mbox │ PEP rsp │
│ ~50µs │ ~200µs │ ~5µs │ ~100µs │~500µs │ ~5µs │ ~50µs │
└──────────────────────────────────────────────────────────┘
↑
THIS is what we're optimizing
(DP DB writes: ~500µs → target: ~200µs)
Key Takeaways
- Session establishment involves multiple DB writes in DP (TEIDs, UEIP, L2TP, etc.)
- Currently: N individual SETs, pipelined (EVL batching gives 1 TCP write)
- Feature: 1 MSET command (less Redis parsing, 1 callback, atomic, clearer code)
- DP DB writes are the biggest latency contributor in the PFCP path
- Reducing DB overhead = lower latency + less CPU per session