On Tue, 16 Jun 2026 13:37:34 +0100
Bruce Richardson <[email protected]> wrote:
> On Tue, Jun 09, 2026 at 02:02:01PM -0700, Stephen Hemminger wrote:
> > This is an RFC for an alternative way to capture packets from a DPDK
> > application. I did brief demo of similar mechanism at DPDK summit but
> > this is more complete. Capture runs in the primary process and is driven
> > entirely over telemetry; no secondary process is involved.
> >
> > A client asks the application to start capturing and passes it a file
> > descriptor to write to. The application writes pcapng to that descriptor.
> > A Wireshark extcap script is the intended front end, but the control path
> > is just telemetry and the output is just a pipe, so other front ends are
> > possible.
> >
> > 1/4 telemetry: let a command receive file descriptors from the client
> > 2/4 capture: the library
> > 3/4 test: functional test
> > 4/4 app: the Wireshark extcap script and its documentation
> >
> > Setup and usage are in doc/guides/tools/wireshark_extcap.rst.
> >
> > Primary process only for now; secondary-process capture is possible as
> > follow-on. Posting as RFC to get feedback on the approach.
> >
> > The extcap script is dual licensed (BSD-3-Clause OR GPL-2.0-or-later) as
> > it may be more useful in the Wireshark tree.
> >
>
> One concern I have though - does this cause system-calls to be made in the
> fast-path because we are writting to a passed in FD? For performance
> reasons, would it not be better to use a memory buffer for this, thereby
> avoiding syscalls? For example, rather than passing in an FD to telemetry,
> we could pass in a key to be passed to shmget (going old-school!), or
> name parameter for shm_open. Thereafter with the memory buffer we can use a
> circular ring or similar to pass the data from app to client.
>
> /Bruce
The system calls are contained inside the thread spawned when capture starts.
The flow is:
callback -> ring -> capture thread -> FIFO -> wireshark
