xdp-trafficgen not generating traffic to another interface in skb mode

[Rogério Rocha]

Hello I am currently trying to generate traffic from an interface that is linked to another by the ip link tool (veth1-veth2)

They are in different namespaces. The trafficgenerator works if the receiving interface is running:
xdp-bench pass veth1

while I am doing this in the generating interface:
xdp-trafficgen udp veth2

Now if I run:
xdp-bench pass -m skb veth1

and generate traffic with the same command as above, there are no packets being transmitted. Why is this?

For reference I am running ubuntu 22.04 LTS

Additionally, in any of the modes, my trafficgenerator seems to reduce performance if I increase the threads used, what could possibly explain this behaviour?
With 1 thread:

With 4 threads:

[Toke Høiland-Jørgensen]

Rogério Rocha ***@***.***> writes:

Hello I am currently trying to generate traffic from an interface that is linked to another by the ip link tool (veth1-veth2) They are in different namespaces. The trafficgenerator works if the receiving interface is running: xdp-bench pass veth1 while I am doing this in the generating interface: xdp-trafficgen udp veth2 Now if I run: xdp-bench pass -m skb veth1 and generate traffic with the same command as above, there are no packets being transmitted. Why is this?

XDP_REDIRECT only works on veth if you load an XDP program (in native mode) on the peer interface. Which xdp-bench does, but not if you run it in skb mode. On recent kernels you can enable GRO on both veth devices and get XDP_REDIRECT working without loading any XDP programs, in which case SKB mode should work as well.

Additionally, in any of the modes, my trafficgenerator seems to reduce performance if I increase the threads used, what could possibly explain this behaviour?

Locking contention, probably? Did you increase the number of RX/TX queues accordingly?

[Rogério Rocha]

I will give it a go once I am able to sit down in front of this again.

As for the RX/TX suggestion, it's weird, because this behavior only happens on the PASS, while on the DROP the threading scales just fine.

[Toke Høiland-Jørgensen]

Rogério Rocha ***@***.***> writes:

I will give it a go once I am able to sit down in front of this again. As for the RX/TX suggestion, it's weird, because this behavior only happens on the PASS, while on the DROP the threading scales just fine.

Well, DROP immediately recycles the frame whereas with PASS it goes through the whole stack, so there's more work being done (and I wouldn't be surprised if there was some synchronisation overhead somewhere in that)

[Rogério Rocha]

An update: It was indeed GRO that was disabled on both interfaces. I had assumed it would be on by default as it does for real interfaces, however seems like it is not the case.

Thank you very much.