DPDK: Problem with Rx offloads capabilities

Question

I'm trying to set environments to test programs written in the P4 language, using t4p4s as the compiler. When a P4 program is compiled with t4p4s, a C/C++ program using DPDK is generated, which in turn is compiled and run.

Compiling the program works fine. The resulting executable is run like so:

./build/l2switch -c 0xc -n 4 --no-pci --vdev net_pcap0,rx_iface_in=veth3-s,tx_iface=veth3-s,tx_iface=veth3-s --vdev net_pcap1,rx_iface_in=veth5-s,tx_iface=veth5-s,tx_iface=veth5-s -- -p 0x3 --config "\"(0,0,2)(1,0,3)\"" 

On a Raspberry Pi, this works with every network interface I've tried so far (virtual ethernet devices as seen in the command above, the builtin ethernet port and a Realtek USB NIC).

Inside a Ubuntu 21.04 VM using virtual ethernet devices, I get the following error:

--- Init switch
EAL: Detected CPU lcores: 4
EAL: Detected NUMA nodes: 1
EAL: Detected shared linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: VFIO support initialized
TELEMETRY: No legacy callbacks, legacy socket not created
2  :::: Allocating DPDK mbuf pool on socket 0
2  :::: Init ports
2  :::: Init port 0
2  :::: Creating queues: nb_rxq=1 nb_txq=2
Ethdev port_id=0 requested Rx offloads 0xe doesn't match Rx offloads capabilities 0x0 in rte_eth_dev_configure()
EAL: Error - exiting with code: 1
  Cause: Cannot configure device: err=-22, port=0

I've had this problem pop up on the Raspberry Pis too, but it would fix itself after a restart or enough tries. On the VM, this problem is persistent.

Questions:

In both cases, I'm using virtual ethernet devices for the interfaces. Both cases use the same driver and software NIC. How can I find out what the difference between the VM and the Raspberry Pi is? After all, if there was no difference then it would work in both cases.

What does the error try to tell me? I've tried searching for it online to no avail and my knowledge of DPDK is very limited.

What can I try in order to fix this issue?

Answer 1

Solved it!

While looking through the files to find the program listing @stackinside requested, I found an argument of t4p4s called "vethmode". There are plenty of arguments like this and I've yet to find a complete documentation for them. Turning that on results in the macro T4P4S_VETH_MODE being defined when the C program is compiled. This in turn changes the composition of a struct rte_eth_conf that is passed to rte_eth_dev_configure some time later.

For the sake of completeness, here is the relevant file.
Line 40 is where the struct rte_eth_conf is defined/initialized.
Line 244 is the start of the function in which the call to rte_eth_dev_configure (Line 261) fails.