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 15:48:45 -0700
>
> On Fri, 2 Oct 2026 00:55:52 +0300
> Vadim Goncharov <vadimnuclight () gmail com> wrote:
>
> > 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.
>
>
> There were several related talks at DPDK summit in Stockholm.
>  https://www.youtube.com/playlist?list=PLo97Rhbj4ceL54ZJHxxcpZljm-Wlx3g4W
>
> But DPDK as infrastructure is going to stick to generic application agnostic
> protocols. If you are building your own system, and you need to capture trace
> data, you probably will end up building your own tools. That is what grout,
> OpenVswitch, and VPP did.
>
> --- 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