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

[Denis Ovsienko <denis () ovsienko info>]

On Mon, 12 Oct 2026 11:19:03 +0200
"Robin Jarry" <rjarry () redhat com> wrote:

> Hi Denis,
>
> Denis Ovsienko, Oct 10, 2026 at 00:12:
> > Consider if the interfaces were arranged as follows:
> >
> > [libpcap]-[socket]-[plugin]-[callable API]-[external packet source]
> >
> > Here the "socket" for the sake of argument could be a Unix domain 
> > socket or a named pipe or the rpcap protocol or a System V IPC
> > message queue, let's for now not compare these alternatives in
> > detail, but focus on two key properties.  Which are that the
> > "socket" has an ID and can provide a bi-directional communication
> > channel between two different processes.  
>
> This is an interesting proposal. You're proposing to make the control 
> socket + ring buffer the official way to capture third party backend. 
> This would be a great fit for grout since this is precisely what we 
> already have:
>
> https://github.com/DPDK/grout/blob/main/modules/infra/api/gr_capture.h
>
> We could adapt/rework this API to go in libpcap.

Thank you for considering it.

The main point is to have, between libpcap and a libpcap plugin, only
an exchange of /data/ over a data-only interface, rather than to
execute the otherwise unaligned /code/ bases as one OS process.

> > It could even be a pair of "sockets" (one for the control requests
> > and responses and another for the packets), or a socket and a ring
> > buffer, as you describe.  It could use a subset or a super-set or a
> > new version of the rpcap protocol, or its own protocol.  The plugin
> > end of such a "socket" could be a standalone process or a function
> > in a larger program.  These are secondary details.  
>
> As I already said, sending the packets in a socket (UNIX or
> otherwise) is not an option because it requires system calls. We
> "could" run an intermediate processes that reads from a shared memory
> ring and copies to a socket but that seems extraneous and we'd prefer
> to reduce the number of moving parts.

That intermediate process/module/function would be your libpcap plug-in.
With the right design of the message exchange it would be entirely up
to you how it integrates with your software stack, so long as it speaks
and acts the protocol correctly.

> However, I don't know if sharing an anonymous ring-buffer [1] in
> memory is possible with all backends that libpcap supports (is there
> file descriptor sharing over SCM_RIGHTS [2] on windows?). There could
> be different options to allow sharing over POSIX shared memory
> segments [3].
>
> [1] https://www.mankier.com/2/memfd_create
> [2] https://www.mankier.com/7/unix#Description-Ancillary_messages
> [3] https://www.mankier.com/3p/shm_open

Let's not over-engineer this aspect in a rush.  A shared ring buffer
could be a protocol option and the mandatory baseline could multiplex
everything over exactly one bi-directional channel.  Not all
programming languages expose all OS APIs, and it seems likely that a
plug-in developer would like to keep things as simple as possible in
the initial proof-of-concept implementation.

One of the typical reasons people capture packets is to debug
functional behaviour rather than performance.  In other words, often to
debug a subject matter problem it is sufficient to establish that what
was supposed to be an exchange of 10 packets has terminated after 5
packets or never started in the first place or a network address was
incorrect.  Capturing at many Mpps is a separate use case, which some
applications just never have (consider DLT_RDS, DLT_MDB, DLT_LORATAP
and the likes).

> As for the control API, anything is on the table. Whatever will be 
> simpler for libpcap. Would you prefer an ad-hoc binary message
> protocol or to reuse netlink for serialization?

It is not a matter of preference, but a matter of how well a solution
space can relate with the problem space.  To that end, Netlink is
Linux-specific, it would add a library dependency and would likely
overshoot the problem space, so it would need to be something else.

-- 
    Denis Ovsienko
_______________________________________________
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