Re: [PATCH v4 0/3] wireshark capture implementation

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 13 Oct 2026 16:28:41 +0800
fengchengwen <fengchengwen@huawei.com> 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.