Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lower throughput with only one thread in vxlan test #2

Open
gvrose8192 opened this issue Aug 11, 2021 · 0 comments
Open

Lower throughput with only one thread in vxlan test #2

gvrose8192 opened this issue Aug 11, 2021 · 0 comments

Comments

@gvrose8192
Copy link

I've been running the test-ovs-vxlan.sh script to help me understand how Mellanox TC based HW offloads work and I've found something a bit odd. The iperf test in the script uses 3 threads and when HW offloads are enabled the total throughput is usually at least double or more than when the offloads are disabled. However, while trying different numbers of threads I found that a single thread will produce higher throughput with HW offloads disabled. Once two or more threads are used then the HW offload throughput is higher than without the HW offloads.

Do you know why a single thread would be faster with HW offloads disabled?
roidayan pushed a commit that referenced this issue Feb 9, 2022
@GavinLi-NV @roidayan
test-ovs-ct-scapy-uni-traffic.sh: Unidirectional traffic offload test
0d0bc61 
This test will verify unidirectional UDP offload via 4 test scenarios:

Case #1: TCP cons in 'new' state will not be offloaded

Case #2: UDP cons in 'new' state will be offloaded - After warm up
unidirectional UDP traffic, unidirectional UDP packets can not be captured
via REP.

Case #3: UDP cons changed to 'est' state will remove 'new' from hw and be
offloaded again - After unidirectional UDP traffic were offloaded, send
response packets from the other side to make the UDP connections' CT state
changed to 'est' and the offloaded rule for the unidirectional UDP flows
will be removed from hw and new rules for the 'est' UDP flows will
offloaded. During this period, packets will can be captured again via REP.
After the switchover, there will be no packets can be captured via REP.

Case #4: UDP cons in 'new' state scale test - scale test for unidirectional
UDP flow offload

Issue: 2829954
Change-Id: Ie18de3a8c77e40bc4a397e50179118c6bd924827
Signed-off-by: Gavin Li <gavinl@nvidia.com>
roidayan pushed a commit that referenced this issue Oct 27, 2022
@GavinLi-NV @roidayan
test-ovs-ct-scapy-uni-traffic.sh: Unidirectional traffic offload test
7eb00cf 
This test will verify unidirectional UDP offload via 4 test scenarios:

Case #1: TCP cons in 'new' state will not be offloaded

Case #2: UDP cons in 'new' state will be offloaded - After warm up
unidirectional UDP traffic, unidirectional UDP packets can not be captured
via REP.

Case #3: UDP cons changed to 'est' state will remove 'new' from hw and be
offloaded again - After unidirectional UDP traffic were offloaded, send
response packets from the other side to make the UDP connections' CT state
changed to 'est' and the offloaded rule for the unidirectional UDP flows
will be removed from hw and new rules for the 'est' UDP flows will
offloaded. During this period, packets will can be captured again via REP.
After the switchover, there will be no packets can be captured via REP.

Case #4: UDP cons in 'new' state scale test - scale test for unidirectional
UDP flow offload

Issue: 2829954
Change-Id: Ie18de3a8c77e40bc4a397e50179118c6bd924827
Signed-off-by: Gavin Li <gavinl@nvidia.com>
roidayan pushed a commit to roidayan/ovs-tests that referenced this issue Feb 13, 2023
@roidayan
test-ct-nic-tcp.sh, test-ct-nic-tcp-vf-legacy.sh: Fix hw_packets counter
aa0115c 
On bf2 kernel, hw_packets only exists in the last action. Get the
counter from the last action to make all kernels pass for this test.

The missing commit d4d9d9c53bef ("sched: act_pedit: Implement stats_update callback")

filter protocol ip pref 1 flower chain 2 handle 0x2
  eth_type ipv4
  ip_proto tcp
  ip_flags nofrag
  ct_state +trk+est
  in_hw in_hw_count 1
        action order 1:  pedit action pipe keys 1
         index 3 ref 1 bind 1 installed 1564 sec used 400 sec firstused 1562 sec
         key #0  at ipv4+8: add ff000000 mask 00ffffff
        Action statistics:
        Sent 28707472 bytes 19811 pkt (dropped 0, overlimits 0 requeues 0)
        backlog 0b 0p requeues 0

        action order 2:  pedit action pipe keys 4
         index 4 ref 1 bind 1 installed 1564 sec used 400 sec firstused 1562 sec
         key #0  at eth+4: val 00000c42 mask ffff0000
         key Mellanox#1  at eth+8: val a158ab99 mask 00000000
         key Mellanox#2  at eth+0: val 0c42a158 mask 00000000
         key Mellanox#3  at eth+4: val ab910000 mask 0000ffff
        Action statistics:
        Sent 28707472 bytes 19811 pkt (dropped 0, overlimits 0 requeues 0)
        backlog 0b 0p requeues 0

        action order 3: csum (iph, tcp) action pipe
        index 2 ref 1 bind 1 installed 1564 sec used 400 sec firstused 1562 sec
        Action statistics:
        Sent 28707472 bytes 19811 pkt (dropped 0, overlimits 0 requeues 0)
        backlog 0b 0p requeues 0

        action order 4: mirred (Egress Redirect to device enp8s0f1) stolen
        index 2 ref 1 bind 1 installed 1564 sec used 0 sec firstused 1562 sec
        Action statistics:
        Sent 6098268655490 bytes 4018559682 pkt (dropped 0, overlimits 0 requeues 0)
        Sent software 28707472 bytes 19811 pkt
        Sent hardware 6098239948018 bytes 4018539871 pkt
        backlog 0b 0p requeues 0

Issue: 3310161
Change-Id: If581e31be54a85681468e7a21f627378411d78c8
Signed-off-by: Chris Mi <cmi@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@gvrose8192