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

AspectPipelined SETsMSET
Redis commands parsedN1
Redis replies generatedN1
Callback overhead in appN callbacks1 callback
Bookkeeping (pending counter)Yes (complex)No (single op)
AtomicityNo (partial failure possible)Yes (all-or-nothing)
Code clarityScattered writesExplicit "these are related"

Session Modification and Deletion

Same pattern applies:

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