On 14/05/2024 07.43, Sebastian Andrzej Siewior wrote:
On 2024-05-14 07:07:21 [+0200], Jesper Dangaard Brouer wrote:
pktgen_sample03_burst_single_flow.sh has been used to send packets and
"xdp-bench drop $nic -e" to receive them.
Sorry, but a XDP_DROP test will not activate the code you are modifying.
Thus, this test is invalid and doesn't tell us anything about your code
changes.
The code is modifying the XDP_REDIRECT handling system. Thus, the
benchmark test needs to activate this code.
This was a misunderstanding on my side then. What do you suggest
instead? Same setup but "redirect" on the same interface instead of
"drop"?
Redirect is more flexible, but redirect back-out same interface is one
option, but I've often seen this will give issues, because it will
overload the traffic generator (without people realizing this) leading
to false-results. Thus, verify packet generator is sending faster than
results you are collecting. (I use this tool[2] on generator machine, in
another terminal, to see of something funky is happening with ethtool
stats).
To workaround this issue, I've previously redirected to device 'lo'
localhost, which is obviously invalid so packet gets dropped, but I can
see that when we converted from kernel samples/bpf/ to this tool, this
trick/hack is no longer supported.
The xdp-bench[1] tool also provide a number of redirect sub-commands.
E.g. redirect / redirect-cpu / redirect-map / redirect-multi.
Given you also modify CPU-map code, I would say we also need a
'redirect-cpu' test case.
Trick for CPU-map to do early drop on remote CPU:
# ./xdp-bench redirect-cpu --cpu 3 --remote-action drop ixgbe1
I recommend using Ctrl+\ while running to show more info like CPUs being
used and what kthread consumes. To catch issues e.g. if you are CPU
redirecting to same CPU as RX happen to run on.
--Jesper
[1] https://github.com/xdp-project/xdp-tools/tree/master/xdp-bench
[2]
https://github.com/netoptimizer/network-testing/blob/master/bin/ethtool_stats.pl
