pcap-dpdk.c fails to compile using DPDK 22.11.7

[infrastation]

Steps to reproduce:

1. Get a Debian 12 host.
2. apt-get install pkg-config dpdk-dev
3. Build libpcap normally.

pcap-dpdk.c:200:18: error: 'struct rte_eth_rxmode' has no member named 'split_hdr_size'
pcap-dpdk.c:203:28: error: 'ETH_MQ_TX_NONE' undeclared here (not in a function); did you mean 'RTE_ETH_MQ_TX_NONE'?
pcap-dpdk.c:328:22: error: variable 'gather_len' set but not used [-Werror=unused-but-set-variable]
pcap-dpdk.c:500:38: error: 'ETH_LINK_UP' undeclared (first use in this function); did you mean 'RTE_ETH_LINK_UP'?
pcap-dpdk.c:836:48: error: 'DEV_TX_OFFLOAD_MBUF_FAST_FREE' undeclared (first use in this function); did you mean 'RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE'?
pcap-dpdk.c:973:62: error: 'ETH_LINK_FULL_DUPLEX' undeclared (first use in this function); did you mean 'RTE_ETH_LINK_FULL_DUPLEX'?
pcap-dpdk.c:501:1: error: control reaches end of non-void function [-Werror=return-type]

[guyharris]

Is it worth the effort to provide a libpcap module that depends on a set of APIs that appears to continuously change in incompatible ways? Or should we just get rid of pcap-dpdk.c? At some point I remember either an email to tcpdump-workers or another list, or a comment on an issue or pull request, saying that the current pcap-dpdk.c isn't doing DPDK capture right (and indicating what at least one problem was), suggesting what a better way would be and, I think, talking about submitting a replacement.

[infrastation]

There is quite a bit of traffic on DPDK mailing lists, perhaps there is someone there would would be willing to make it good?