dpdk: refactor use rte_pktmbuf_read instead of dpdk_gather_data

[idogoshen]

Use dpdk standard function rte_pktmbuf_read instead of custom made code

pcap-dpdk will now support packet size up to 16K as defined in pcap-dpdk.c#L168: #define RTE_ETH_PCAP_SNAPLEN RTE_ETHER_MAX_JUMBO_FRAME_LEN.
In case anyone thinks more is needed then pcap-dpdk.c#L198 pcap_tmp_buf can be increased to 64K.

relates to #1543

[mcr]

Hi, we have decided that testing against DPDK is more than The Tcpdump Group can reasonably do.
We looking for someone from the DPDK team to review all such submissions. Are you a core DPDK person? Maybe you can refer one.

[guyharris]

Hi, we have decided that testing against DPDK is more than The Tcpdump Group can reasonably do.

In particular:

We can do "smoke tests" to make sure that changes will compile, by building on a (virtual or real) machine with the DPDK SDK installed. However, people submitting changes to pcap-dpdk.c have presumably already done that.

We don't, as an organization, have any machines with DPDK-supporting hardware to allow us to test the changes; perhaps some individuals have that, but they may not have the time to do so. People submitting changes to pcap-dpdk.c probably have that.

I don't know whether any libpcap core developers are sufficiently familiar with the DPDK libraries to be able to review those changes. That's why:

We looking for someone from the DPDK team to review all such submissions. Are you a core DPDK person? Maybe you can refer one.

Part of the problem is that the DPDK APIs don't appear to be "stable" in the sense that code written to older versions will continue to compile; #1159 is an example of the sort of problems that result from that. We don't have the resources to track the DPDK API's changes and update the code to make it compile, so a DPDK team member needs to take that role if libpcap is to continue to support DPDK.

Similarly, we don't have the resources to look into whether the return value of dpdk_gather_data() needs to be used or can be discarded; that you for looking into it and submitting #1546 - and for knowing enough about the DPDK API to suggest this pull request.

DPDK seems to be more complicated than the APIs offered by various operating systems for doing network packet capture, and thus supporting it in libpcap needs the help of DPDK specialists who have the knowledge, time, and energy to provide that support.

So if you, or somebody you know, can "own" pcap-dpdk.c, that would be very helpful.

[fxlb]

FYI:
https://mails.dpdk.org/archives/dev/2025-March/315377.html

[guyharris]

Somebody suggested, at one point, a complete redo of the DPDK code to use a different mechanism, in terms similar to what Stephen Hemming said (for example, I think they spoke of allowing regular and capture DPDK use at the same time), but I couldn't seem to find it anywhere in my mailbox the last time I looked (either as a direct email or an email for a comment in an issue/pull request). I think they talked about working on such a redo, but I never heard any more about it.

[idogoshen]

Hi

Unfortunately I cannot commit to take ownership as I’m full time busy at a commercial company but I’d try to contribute on best effort basis. I’m not a core DPDK member, but do have decent knowledge being a heavy DPDK user and constantly working in DPDK environments.
In our product we use dpdk to dispatch traffic to third-party/legacy processes that use libpcap for packet acquisition. I can share more info if that's interesting.

Thanx
Ido

[idogoshen]

In related to @fxlb #1547 (comment)

feature/dpdk-ring branch adds option to use libpcap as secondary dpdk process. It can be used not only for capture per se but enables packet acquisition from dpdk for legacy libpcap using apps.

For more details see: README.dpdk-ring.md

Should I open pull request for it?