On Tue, 13 Oct 2026 16:28:41 +0800 fengchengwen <[email protected]> wrote:
> Hi Stephen, > > A live Wireshark capture capability via extcap and telemetry is a highly > anticipated > feature for runtime debugging. In our previous high-throughput testing with > file-based > captures, we frequently encountered severe bottlenecks where packets could > not be written > to disk fast enough, leading to massive ring buffer overflows and packet > drops. > Therefore, the implementation details of this feature are of great interest > to us. Live capture into Wireshark will not help if disk can't keep up; Wireshark is slower than disk. For high rate, use a capture filter and a short snaplen. Existing dpdk-dumpcap can already feed Wireshark through a pipe. > Reviewing the current v4 architecture, I have two major concerns: > > 1) Security Aspect & Telemetry Attack Surface > The introduction of control operations (such as dynamically registering rx/tx > callbacks and passing arbitrary FIFO paths) drastically expands the attack > surface of the otherwise read-only telemetry interface. Could we introduce > a dedicated "debug mode" configuration to strictly guard these write paths? > Furthermore, it would be beneficial to know if this mode plans to support > more control interfaces down the road, such as a "stats_reset" command. I am going to add a "--no-capture" option to command line like "--no-telemetry". The problem is that if the feature is "opt-in" then users have trouble using especially if command line is buried in application. The launchpad script already has lots of hardening to let it run with privilege escalation. It resets itself after opening the socket. This is to allow setups (which is normal on most Linux distros) where any user in group wireshark can run capture. The capture setup does checks to make sure that it can only be passed a FIFO and rejects symlinks etc. The telemetry socket already has same permissions as the DPDK primary process. I.e if you can get to the telemetry you can read/modify shared memory etc. Not sure where Bruce intends to go with telemetry The other option is making a clone of telemetry (different socket and startup) but that duplicates effort. > 2) Performance Impact & Thread Isolation > The current implementation enforces a deep copy for captured packets. Have > you considered an adaptive approach? For instance, allowing a lightweight > shallow copy (mbuf clone) under certain conditions to save CPU cycles, while > reverting to a deep copy only when conflicting offloads (like FAST_FREE) > are active on the TX path. Looked at this before but: - Rx: most applications assume the mbuf is writeable and having a capture break application is non starter. - Tx: many drivers assume the mbuf is writeable (arguably a bug). - FAST_FREE requires refcnt == 1. - A clone pins the original buffer. If the reader falls behind, the capture ring holds Rx mempool buffers and can starve the NIC. The most efficient way to handle this is to set snapshot length and get the relevant headers. > Additionally, how is the actual packet writing thread managed and controlled? > To prevent I/O blocking from introducing jitter into the fast path, should > we consider isolating this writing worker thread onto a dedicated, isolated > core (ecore/lcore)? The writer is just a control thread, it is going to block on the FIFO write system call if reader does not keep up. Then the packets back pressure is in the ring. The callback increments a statistic if ring is full. The capture writers inherit the control cpuset so already isolated.
