Measuring slirp4netns Overhead Before Switching to pasta in Rootless Podman

Podman defaults to the slirp4netns user-mode network stack for rootless containers, which introduces context-switch overhead compared to kernel-level bridging. The pasta backend was added as a more efficient alternative, yet the performance gap varies with kernel version, CPU architecture, and distribution-specific netns or cgroup v2 implementations.

Before changing the default backend or tuning sysctl parameters, a reliable baseline is needed to quantify the actual throughput and latency penalty for a given workload. Existing benchmarks often test synthetic traffic rather than application-specific patterns such as short-lived connections or large file transfers.

Which metrics most reliably expose the slirp4netns bottleneck for a specific workload? Does the overhead manifest primarily in bandwidth, connection establishment latency, or CPU utilization? When does the pasta backend provide a measurable improvement without introducing compatibility regressions?