DPDK: add explicit mtu= URI option and size RX mbufs independently of snaplen

[ppjablonski]

Hi,

I have been testing OpenLI/libtrace with the DPDK input format on Ubuntu LTS using DPDK 23.11.4 and a Broadcom BNXT NIC. I hit a problem with jumbo frames / increased MTU handling in lib/format_dpdk.c.

Problem

The current DPDK code path appears to couple jumbo frame configuration and RX mbuf sizing to snaplen. This is problematic with newer DPDK APIs, where rxmode.max_rx_pkt_len has been removed and rxmode.mtu / rte_eth_dev_set_mtu() should be used instead.

It is also semantically wrong to treat snaplen as MTU:

• snaplen is a capture length limit.
• MTU is a port / NIC configuration parameter.

With BNXT, simply setting a larger MTU is not sufficient if the RX mbuf pool remains too small and scattered RX is not enabled. Since libtrace's DPDK path appears to expect packet data to be accessible in a single contiguous mbuf, enabling scattered RX is not a safe fix.

Real-world impact

The issue is visible when capturing traffic with frames larger than the standard Ethernet payload, for example access traffic with QinQ and PPPoE overhead.

In one failed capture before this patch, the extracted TCP/FTP object had the following sizes:

ls -la 193.219.028.002.62316-100.112.063.182.35753
-rw-rw-r-- 1 user user 4186112000 Jun  5 13:43 193.219.028.002.62316-100.112.063.182.35753

du -h 193.219.028.002.62316-100.112.063.182.35753
177M    193.219.028.002.62316-100.112.063.182.35753

So the reconstructed file had an apparent size of about 4.19 GB, but only about 177 MiB were actually allocated on disk. This means that most of the reconstructed object was effectively sparse / missing data. In this test case, only about 4.4% of the logical object size was backed by real data.

This is particularly problematic for lawful intercept / full-content capture use cases, because the resulting reconstructed object can have the expected logical size while still being unusable or corrupted.

Proposed change

The attached patch adds support for an explicit DPDK URI option:

dpdk:0000:84:00.0?mtu=9000

The patch:

• parses mtu= from the DPDK URI,
• keeps snaplen untouched,
• strips the query string before passing the device identifier to DPDK / PCI parsing,
• uses port_conf.rxmode.mtu for newer DPDK,
• calls rte_eth_dev_set_mtu() and verifies the effective MTU with rte_eth_dev_get_mtu(),
• increases RX mbuf payload room based on the requested MTU,
• avoids enabling scattered RX.

Environment tested

• OS: Ubuntu 24.04.4 LTS

• DPDK: 23.11.4

• OpenLI: 1.1.18 from the WAND / Cloudsmith repositories

• NIC / PMD: Broadcom BNXT

• Application: OpenLI collector

• URI tested:

  dpdk:0000:84:00.0?mtu=9000

The traffic path included larger-than-standard access frames due to QinQ + PPPoE overhead.

dpdk:0000:84:00.0?mtu=9000

The traffic path included larger-than-standard access frames due to QinQ + PPPoE overhead.

Validation of a Debian live ISO captured through OpenLI/libtrace/DPDK.## Validation

Extracted FTP data stream SHA256:

654f09b24bf2f2432d11f55c1a24da480384ca45126007067befae86be9993e0

Original ISO SHA256:

654f09b24bf2f2432d11f55c1a24da480384ca45126007067befae86be9993e0

The hashes match, confirming that the captured stream was not truncated or corrupted.

Patch

Attached:

0001-format-dpdk-add-explicit-mtu-uri-option.patch

I am happy to adjust the patch if you prefer a different URI option name, error handling style, or if you would rather expose this as a formal libtrace configuration option instead of a URI parameter.
``

[salcock]

Thank you for reporting this and thank you even more for providing a patch.

I'll try to review and test this out soon, but just wanted to post a comment here to acknowledge that I've seen it and appreciate it 🙏