Measuring slirp4netns Overhead Before Switching to pasta in Rootless Podman

Direct Answer

Which metrics expose the slirp4netns bottleneck? Three key numbers:

• Connection‑establishment latency (TCP handshake)
• Sustained throughput on large data transfers
• CPU usage per packet (context‑switch rate)

Where does the overhead show up? For short‑lived connections the latency spikes (2–3× higher than kernel bridging). For bulk transfers the bandwidth drop is more visible (30–40% lower on kernels 5.15+). CPU usage climbs because each packet is copied from user space into the kernel, adding a context switch.

When does pasta help? On kernels ≥5.10 that support the BPF‑based passthrough, pasta delivers near‑kernel latency and higher throughput with minimal compatibility regressions for standard TCP/UDP workloads. On older kernels pasta will silently fall back to slirp4netns, so the benefit disappears.

Measurement Steps for Your Workload

1. Check prerequisites

   uname -r
   podman --version
   

   Verify kernel ≥5.10 and Podman ≥4.0.

2. Baseline with slirp4netns (default)

   # Simple HTTP server in a container
   podman run -d --name slirp-test -p 8080:8080 alpine/httpd
   
   # Throughput test – iperf3 server inside the container
   podman exec slirp-test iperf3 -s -p 5201 &
   iperf3 -c localhost -p 5201 -t 30
   
   # Connection latency – curl timing
   curl -w "%{time_connect}\n" -o /dev/null -s http://localhost:8080/
   
   # CPU usage during load
   pid=$(podman inspect --format '{{.State.Pid}}' slirp-test)
   pidstat -p $pid 1 10
   

3. Repeat with pasta backend

   podman run -d --name pasta-test --net=pasta -p 8081:8080 alpine/httpd
   
   # iperf3 server inside
   podman exec pasta-test iperf3 -s -p 5202 &
   iperf3 -c localhost -p 5202 -t 30
   
   # curl latency
   curl -w "%{time_connect}\n" -o /dev/null -s http://localhost:8081/
   
   # CPU usage
   pid=$(podman inspect --format '{{.State.Pid}}' pasta-test)
   pidstat -p $pid 1 10
   

4. Optional: Profile context switches

   pid=$(podman inspect --format '{{.State.Pid}}' slirp-test)
   perf record -e sched:sched_switch -p $pid -- sleep 30
   perf report
   

   Look for frequent switches between the container process and the slirp4netns helper.

5. Verify namespace and backend

   ip netns list
   cat /proc/$(podman inspect --format '{{.State.Pid}}' slirp-test)/net/route
   

Interpretation Guide

Metric	slirp4netns	pasta	Action
Connection latency	≈2–3× kernel	≈kernel	Consider pasta if latency >1.5×
Throughput (iperf3)	baseline	+30–40%	Use pasta if gain >20%
CPU % per packet	high	lower	Switch if CPU saturates

Missing Diagnostic Detail

What is your kernel version and distribution? This determines pasta support and cgroup v2 nuances, which can change the recommendation entirely.