Closed wanghuiheze closed 10 months ago
@marceloleitner Do you have any good suggestions or opinions,Thank you!
@wanghuiheze Sorry for the delayed reply but all flows that are not offloaded have ct_state(0x21/0x29)
. That translates to ct_state=+trk+new
:
#define OVS_CS_F_NEW 0x01 /* Beginning of a new connection. */
#define OVS_CS_F_ESTABLISHED 0x02 /* Part of an existing connection. */
#define OVS_CS_F_RELATED 0x04 /* Related to an established
* connection. */
I think it's expected that they're not offloaded.
Yup, sorry the delay as well. I can confirm Dumitru's expectations: +trk+new are NOT offloadable.
Thanks for the confirmation @marceloleitner! Closing this for now.
Test the sNAT hardware offload Experimental environment:
View the ovn database:
Some information about the gateway01 chassis is listed below
10.199.100.10 -> 172.31.6.24 (snat(src=123.123.123.123))
1.With the iperf3 test, there seems to be no problem, all flows are unloaded normally, and the traffic is as expected.
2.Using dperf to test udp packets, it was found that some flows were not offloaded, and the traffic did not meet the expected value. The CPU occupied 100% of the ksoftirqd process
According to the flow table, the two flows are not offloaded.But I don't know why.
3.Testing tcp packets with telnet found that some streams were not offloaded.
According to the flow table, the two flow are not offloaded.But these two flow do not seem to be used(used:never),I don't know if this access is a normal offload,Just from the flow table of type=offload the offload is normal.
I did not test the case of dperf sending tcp packets, I will add that after the subsequent tests. The question now is why are there some flows that cannot be offload in the second and third cases.What do I need to do to offload these flows.
I really hope to get your help. If you need any information, I will supplement it.The attachment is the result of the ovs-ofctl dump-flows br-int command
slowpath.txt