Re: RFC: a loadable plugin framework for external capture backends

[Vadim Goncharov <vadimnuclight () gmail com>]

On Thu, 1 Oct 2026 09:29:49 -0700
Stephen Hemminger via tcpdump-workers <tcpdump-workers () lists tcpdump org>
wrote:

> On Wed, 30 Sep 2026 22:28:45 +0200
> Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > Hello,
> >
> > Following Denis Ovsienko's suggestion on GitHub PR #1659 [1], we 
> > (Vincent Jardin, the author of the PR, and Robin Jarry) are jointly 
> > moving the discussion of a libpcap plugin framework here, to the mailing 
> > list, as the tcpdump.org front page recommends for major changes. This 
> > message is deliberately about the problem and the shape of a solution, 
> > not about the code currently in the PR. Our goal is to reach agreement 
> > on whether the idea is worth pursuing and, if so, on a specification we 
> > can all reason about before any code is reviewed for merge.  
>
> On Wed, 30 Sep 2026 22:28:45 +0200
> Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > Existing remote-capture solutions such as rpcapd do not help here
> > either: they require the dataplane to write every captured packet to
> > a TCP/UDP socket, i.e. a system call and a copy per packet, which is
> > unacceptable on the multi-Mpps data path these dataplanes are built
> > to sustain.  
>
> I support having a plugin loader in libpcap, but this paragraph is
> not correct for DPDK.
>
> There is a dpdk-rpcapd series under review on dev () dpdk org [1]. It
> runs as a secondary process and uses the same pdump hooks as
> dpdk-dumpcap. The forwarding thread copies the mbuf and enqueues it
> on a ring. The socket write is done by the daemon on another core.
> The dataplane never makes a system call and never blocks.
>
> The real problem is more general: fast bulk transfer of packets
> between processes across a domain boundary, with some mechanism for
> access control (which could be just file permissions). A socket is
> one answer, shared memory is another.

Interesting topic. I am (at work) doing an Anti-DDoS/firewall system on DPDK
(currently at design stage), and customer admins want to be able to capture
packet by specifying keywords in rules. For this, I've selected pflog format
(from OpenBSD/FreeBSD pf firewall) which adds a header to each packet with
ruleset name, rule number, match reason (allow, drop, etc.) and so on, because
Wireshark can decode pflog header. Then, as it is not possible to capture
directly, I suppose to have secondary process which shares ring buffers
memory with primary and consumes mbufs (tagged with rule info), writing .pcapng
files to disk (to have comments etc.), exactly because as running
tcpdump/Wireshark directly on DPDK interfaces is not possible.

Given discussed proposal, may be you have some recommendations on how to
change this architecture in the light of upcoming plugins? I was not aware of
neither grout nor dpdk-rpcapd before this thread.

> That is the case for a plugin mechanism. It allows experimentation
> and development of these transports without building each one into
> libpcap.
>
> [1] https://patchwork.dpdk.org/project/dpdk/list/?series=39468


-- 
WBR, @nuclight
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s