Supported topologies with/without SFs and OVS bridges

Infrastructure & Networking BlueField
1

Hi all,

I am deploying a small subset of our Bluefield-2 DPUs as a simple software firewall + NAT appliance where the DPU sits between the uplink port and a host that needs to be secured. My main question is how the port representers + OVS bridges should look and if they are required at all. In the DOCA NAT example there are two OVS bridges and two SFs in use.

image
image632×1104 80.8 KB

So for the above topology in my use case it would be the same:
external net <-> p0 <-> ovsbr2 <-> sf1 <-> DPU <-> sf0 <-> ovsbr1 <-> pf0hpf <-> host

I have tested this layout and it seems to work, but there’s a lot of complexity for a simple app.

However, there are notable examples also in the DOCA Docs like the IPSec example where at lease one of the physical ports seems to be connected directly to the DPU:

image
image990×1356 103 KB

So my question is, are any of the following three topologies also valid and supported for my application:

  1. external net <-> p0 <-> DPU <-> sf0 <-> ovsbr1 <-> pf0hpf <-> host
  2. external net <-> p0 <-> ovsbr1 <-> sf0 <-> DPU <-> ovsbr2 <-> pf0hpf <-> host
  3. external net <-> p0 <-> DPU <-> pf0hpf <-> host

I’ve had a couple issues configuring (1, 3) to work at all, but I have gotten (2) to work consistently on Linux when I manually assign an IP to ovsbr2 directly (NO SF between host and DPU). However, I’m suspicious that this is not a supported config.

I’ve read the Scalable Function docs and they don’t seem to make it clear if sfs and OVS bridges are required for passing frames between the host/dpu or dpu/uplink.

2

basiclly you can consider SF as light weight VF. Without L2 bridge or app forward L2 package, P0 can’t go to sf0, that’s why ipsec docs figure show ipsec gateway is there.

Hope I answered your question.

3

basiclly you can consider SF as light weight VF. Without L2 bridge or app forward L2 package,

That makes sense, I guess my remaining underlying question is:

Are the physical port representors (p0 an pf0hpf) meant to be attached directly to the Bluefield ARM CPU? It seems like SFs/VFs are very commonly used in the docs, but if I can directly attach the physical ports it’s not clear what the benefit of using them in the single “bump on wire” case is.

4

No port or port rep attach to ARM. All these port attached on e-switch. In DPU mode of BF, these rep mainly use for flow rules management of OVS. Eg, you can set NIC flow rules, ACL, ECPF on rep port then HOST side pf/vf port will effect, no need do something on host, it is offload.

What’s the purpose of ARM CPU? :-), it is for ovs and ruls management, also for virtio-net, and for DPDK SPDK (also offload to e-switch) app.

rep port model, FYI.

https://docs.nvidia.com/networking/display/bluefielddpuosv470/kernel+representors+model

5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.