ASAP2 - Supported Actions - Forward from one physical port to another physical port on the same NIC with hardware acceleration

Infrastructure & Networking Adapters and Cables Ethernet Adapter Cards
1

In the ASAP2 documentation for supported actions, it notes that the Forward action allows for packet redirection:

  • From VF to wire
  • Wire to VF
  • VF to VF

In my use case, I would like to have support for offloaded (hardware accelerated) flows from Wire to Wire (ex: one physical NIC interface, to the other physical NIC interface on the same physical card). This type of support would allow a ConnectX-[5,6,7] NIC to provide network filtering for traffic passing from one NIC port to another (on the same card) in support of building network appliances where there are no applications of interest on the host housing the NIC card itself. While I can use OVS to forward traffic between physical ports on the same ConnectX NIC, the flows do now show up as offloaded via:

ovs-appctl dpctl/dump-flows type=offloaded

Is there any way to accomplish hardware offload from physical port to physical port on the same NIC? If not, is there are hardware limitation that prevents this? We can accomplish this with other NICs (ex: Netronome).

2

Hi @william.brockelsby ,

OVS and ASAP2 are particularly useful in virtualized environments where you aim to improve the network performance of VMs. By providing VMs with SR-IOV VFs and offloading the hypervisor kernel switching to the hardware, these solutions significantly enhance network efficiency.

If virtualization is not part of your setup and your goal is to receive packets on one port and forward them to another while bypassing kernel overhead, you can use the testpmd DPDK sample application. This tool enables packet reception, resource allocation, queue configuration, CPU affinity setup, and custom traffic flow rules (using rte_flows).

For more information about testpmd, refer to the official documentation:
DPDK Testpmd Application User Guide

Regards,
Chen

3

Hi @chenh1,

Thank you for the reply. I am familiar with DPDK and while it does reduce the kernel overhead as you mentioned, the host CPU is still involved in forwarding frames. Is it possible to have ConnectX (or BlueField) NICs forward traffic from port-to-port on the same NIC, with specified filters or other actions, without involving the host CPU at all (ex: fully offload this into the NIC hardware)? This would leave the host CPU free to run other interesting applications (ex: control plane, management plane, etc). If this is not possible at this time is this a hardware limitation of ConnectX / BlueField or a software/driver limitation that could change in the future? Thanks again!