Issue with Packet Reception on Second PF Interface in Multiport E-switch Mode

Dear NVIDIA/Mellanox community,

The newly supported feature, multiport E-switch, is a great feature to facilitate implementation of communication redundancy. However, I’ve encountered an issue where packets arriving on the second interface (e.g., PF1) are not processed by the host machine’s kernel, disrupting the software services on this PF. Additionally, ping requests sent from this interface fail, although communication through the first interface (PF0) remains unaffected.

Following the official setup guide [1] for multiport E-switch mode, once the second PF interface is configured, it seems to stop forwarding packets to the kernel. I’ve also tested with DPDK 23.11, using testpmd to enable isolation mode on both PF interfaces without resolving the issue. The command used was:

sudo ./dpdk-testpmd -a 3b:00.0,dv_flow_en=2,dv_esw_en=1,fdb_def_rule_en=1,representor=pf0-1vf0 -- -i --rxq=1 --txq=1 --flow-isolate-all

I suspect that configuring the second PF interface for multiport E-switch mode somehow alters its role, making it akin to a VF in the E-switch’s view. I would greatly appreciate insights on:

  1. Can the second PF interface, once in multiport E-switch mode, still forward packets to the OS kernel, or does it cease being recognized as a PF?
  2. What steps can I take to restore communication through this PF interface?

Thank you for any assistance or suggestions you can provide.

[1] https://doc.dpdk.org/guides/nics/mlx5.html#multiport-e-switch

hi

Such issue need further debug
You can contact Nvidia Networking support by networking-support@nvidia.com

Thank you
Meng, Shi

Just wondering if the limitation mentioned in the docs doesn’t apply here?
https://doc.dpdk.org/guides/nics/mlx5.html#id2

Matching traffic coming from a physical port and forwarding it to a physical port (either the same or other one) is not supported.

In order to achieve such a functionality, an application has to setup hairpin queues between physical port representors and forward the traffic using hairpin queues.

Hi @dawidwrobel, thanks for pointing out. however, the issue is not about forwarding packets from one PF to another PF using flow rules. It is about the kernel cannot receive packets from PF1 using the isolation mode once the Nic is configured into the multiport eswitch mode.