Questions about DPU Representor Ports on BlueField2

Infrastructure & Networking BlueField
1

Hi,

I’m currently working with the BlueField2 DPU and have been reading through the documentation here: Kernel Representors Model. I’m really interested in the representor port model, but I have a few questions that I’m hoping someone can help clarify:

1. Are Representor Ports Software-Defined or Real Network Interfaces?

I’m a bit confused about whether the representor ports are purely software-defined virtual interfaces or actual physical network interfaces. For instance, when I run ifconfig on the DPU SoC, I see the following output:

ubuntu@localhost:~$ ifconfig
en3f0pf0sf0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether f6:e8:0f:33:bb:c2  txqueuelen 1000  (Ethernet)
        RX packets 1284  bytes 403380 (403.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

en3f1pf1sf0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether de:cc:fa:d1:99:a3  txqueuelen 1000  (Ethernet)
        RX packets 2562  bytes 501550 (501.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2858  bytes 514184 (514.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0f0s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::3a:d1ff:fe09:9c0d  prefixlen 64  scopeid 0x20<link>
        ether 02:3a:d1:09:9c:0d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1284  bytes 406246 (406.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0f1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.200.3  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::b2:eeff:fe75:aa83  prefixlen 64  scopeid 0x20<link>
        ether 02:b2:ee:75:aa:83  txqueuelen 1000  (Ethernet)
        RX packets 2550  bytes 479350 (479.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2562  bytes 504346 (504.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I noticed that enp3s0f1s0 and its representor en3f1pf1sf0 have different MAC addresses. Does this imply that the representor port is a physical device rather than just a virtual one?

2. How Does the ARM Core Track Traffic on the Physical NIC via Representors?

I’m curious about how the ARM core monitors traffic on the physical NIC through representor ports. For example, when the host’s pf1 receives traffic, I also observe traffic on the representor port (pf1hpf).

Does this mean that traffic is duplicated or forwarded to the representor? Or does the representor port not carry actual traffic, but instead reflects hardware metrics from pf1 to the ARM core?

3.DOCA Flow Inspector Observations

I followed the steps in the DOCA Flow Inspector Guide to deploy the Flow Inspector and set up OVS mirroring to mirror traffic from pf1hpf to a sf. Here’s the configuration I used:

ovs-vsctl -- --id=@p1 get port en3f1pf1sf0 \
            -- --id=@p2 get port pf1hpf \
            -- --id=@m create mirror name=m0 select-dst-port=@p2 output-port=@p1 \
            -- set bridge ovsbr2 mirrors=@m

DOCA Flow Inspector version: 2.5.0
DOCA Telemetry Service (DTS) version: 2.8.0

I noticed the following when observing the DTS output:

  • On the representor port pf1hpf, both the receive rate (eth_rx_packets_rate) and transmit rate (eth_tx_packets_rate) are non-zero.
  • However, on the sf(en3f1pf1sf0), only the transmit rate is non-zero, while the receive rate remains at zero.

This seems strange to me because I think the mirrored traffic should appear as incoming traffic on the sf port. Why isn’t the receive rate (eth_rx_packets_rate) showing any activity on the sf?

Any insights or explanations would be greatly appreciated!

Thanks in advance!