On Fri, 12 Dec 2025 00:53:40 -0800 Guy Harris <[email protected]> wrote:
> > This would allow using tcpdump etc while running any of the many > > DPDK routing, switch applications. > > > > The question is should the new code: > > be another capture type: i.e pcap-pdump; or just rewrite existing > > code in pcap-dpdk? > > If it would do a better job of allowing programs to capture network > traffic through a DPDK interface than the current code does (even if > "better" just means "does an equally good job from the point of view > of the program, but is easier to maintain"), then I'm not sure > there's a reason to keep the old code around, just replace the > existing code (even if the "rewrite" means "throw it away and start > from scratch"). Yes. How much of the existing code to preserve, if any, would be up to anyone who can get pcap-dpdk.c into shape. One of the directions of work done in libpcap in recent few years has been removing of modules that could/should not be maintained anymore (e.g. AirPcap, Enetfilter, NIT, Septel, STREAMS NIT, TurboCap and [Tru64/Ultrix] Packet Filter). Another was fixing of various bit rot in the remaining modules where practicable (DAG, DLPI, Haiku, Hurd, SNF). In this sense DPDK support has not ended up as one of these two cases yet. > > Is there a maintainer for the DPDK code in libpcap? > > Not really. I don't know to what extent any of us core developers are > sufficiently familiar to act as maintainers (I'm not). pcap-dpdk.c has been in the source tree for 7 years, most of this time barely maintained and originally developed for DPDK 18.11. Existing libpcap releases cannot build with DPDK newer than 22.11; Ido Goshen has fixed that for the master branch in August 2025 and opened pull request 1547 with another improvement. That said, as a matter of fact, DPDK has not been an area of our collective expertise, so help in this department would be welcome. If you remember, I posted a message along those lines to [email protected] in February 2025, at the time of this writing the invitation still stands, but I am not subscribed to that mailing list now. Stephen, you obviously know the DPDK side of the fence. If you are willing to make any improvements to pcap-dpdk.c, from a libpcap maintainer point of view it would be useful to see the updated code: * practicable to follow and to relate with DPDK documentation * implementing libpcap semantics consistently with other libpcap modules * obviously working in a basic common use case * having an up to date README file For now it would be best to make any such improvements in the master branch only. If everything goes well, in a few months the remaining blockers for libpcap-1.11.0 will be resolved and the improvements will be available in 1.11.0. Any improvements after 1.11.0 would have to be back-ported to libpcap-1.11 after the latter comes into existence, but this would be fine. If you need any additional information to decide, just ask. -- Denis Ovsienko _______________________________________________ tcpdump-workers mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
