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

[Stephen Hemminger via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Stephen Hemminger <stephen () networkplumber org>
>
> Date: Thu, 1 Oct 2026 09:29:49 -0700
>
> 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.
>
> 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
>
> --- End Message ---
_______________________________________________
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