Update DPDK to 22.11

[PlagueCZ]

Updated the codebase and Dockerfile to use DPDK 22.11 LTS.

Changes done:

• moved to Debian 12
• PCI device structures are now hidden, thus the PCI address retrieval is done differently
• ports need to be stopped before exitting to prevent errors (I think only the errors are new, DPDK was just silent before)
• NUMA socket on my machine is not available now, but was previously. I changed the code to support both cases
• removed conditional code from dp_rte_flow (offloading needs to be tested)
• DPDK custom patches reduced to only the custom logging and gcc12 warning in debug, no backported bugfixes anymore
• custom DPDK patch to raise restrictions on telemetry dictionary keys; also added telemetry tests

[PlagueCZ]

@guvenc I implemented the changes needed for the -1 socket id. If you could just take a look at f79fd50 (Added NUMA socket id array check)

I actually changed the macro to unlikely((unsigned int)(SOCKETID) >= DP_NB_SOCKETS) ? 0 : (SOCKETID) because that way we can drop the RTE_VERIFY(socket_id < DP_NB_SOCKETS) that was used previously by all the callers as it would actually abort() the whole process.

Plus there was a bad order of init calls (by me I think), which is the other change in dp_service.c

And since I was touching so many lines, I also renamed some variables to reflect DPDK:

• socketid to socket_id
• vni_value to vni_data because this reflects the rte_hash_*(... void **data)
  Of course I can rename these back if that is not something you like in your code.

[PlagueCZ]

@byteocean Not sure if the last commit that removes the ifdefs in dp_rte_flow are OK, as I cannot really test the hairpins, but offloading is working for the standard VF-VF and inter-host communication.

@guvenc If the above is OK, then I think this is all that is needed to move to DPDK 22. Florin should be back soon, so we should be able to go ahead with the Debian 12 soon which this is based on. But we are using OSC branches anyway, so the next steps regarding this PR are up to you.

[guvenc]

@byteocean Is the removed conditional compilation ok for the offloading path ?
@PlagueCZ
I will need some tests on my side as well before we make this draft a PR but it is in good shape for the testing.

[byteocean]

Hi @PlagueCZ I got the following error/warning during the port starting. Any idea what could go wrong? DPDK version 22.11.3

olated_mode_ipip()]
2023-09-15 11:01:00.052 1(control) D SERVICE: Installed IPIP isolation flow rule, port_id: 0 [../src/rte_flow/dp_rte_flow_init.c:37:dp_install_isolated_mode_ipip()]
2023-09-15 11:01:00.052 1(control) W SERVICE: Cannot get port device info, port_id: 0 [../src/dp_port.c:505:dp_port_start()]
2023-09-15 11:01:00.088 1(control) D SERVICE: Trying to bind peer to port, peer_port_id: 0, port_id: 9 [../src/dp_hairpin.c:109:dp_hairpin_bind()]
2023-09-15 11:01:00.088 1(control) D SERVICE: Trying to bind port to peer, port_id: 9, peer_port_id: 0 [../src/dp_hairpin.c:116:dp_hairpin_bind()]
2023-09-15 11:01:00.088 1(control) I SERVICE: Init isolation flow rule for IPinIP tunnels [../src/dp_port.c:414:dp_port_install_isolated_mode()]
2023-09-15 11:01:00.108 1(control) D SERVICE: Installed IPIP isolation flow rule, port_id: 9 [../src/rte_flow/dp_rte_flow_init.c:37:dp_install_isolated_mode_ipip()]
2023-09-15 11:01:00.108 1(control) D SERVICE: Installed IPIP isolation flow rule, port_id: 9 [../src/rte_flow/dp_rte_flow_init.c:37:dp_install_isolated_mode_ipip()]
2023-09-15 11:01:00.108 1(control) W SERVICE: Cannot get port device info, port_id: 9 [../src/dp_port.c:505:dp_port_start()]

[byteocean]

@PlagueCZ hairpin also works for simple tests (VM2VM, across hypervisor) under this branch. nice to get rid of these flags, and 22.11 seems to be improved a lot.

[PlagueCZ]

Based on your guys' input, I removed the PCI address reporting in gRPC altogether (protocol is kept the same with a comment for the next breaking protocol change) and force-pushed the branch.

[PlagueCZ]

I updated the port handling in another commit. We talked about the TAP device workaround and I also added a rollback for port startup errors, so that needed another function, etc.

[PlagueCZ]

@guvenc confirmed working on TSi staging (3AZ * 3nodes), there will be some load over the weekend, otherwise works perfectly.

This is before the VF-offloaded-packet dump branch was merged.

[PlagueCZ]

I think after the last addition (telemetry fix) this is ready and tested in production.

The checkpatch failure is because of the last addition in C++

[guvenc]

Thanks, I am so glad that we can move to the latest DPDK LTS version.