Re: [RFC PATCH v3 2/2] dts: add PMD RSS testsuite

[Ivan Malov <ivan.malov@arknetworks.am>]

[-- Attachment #1: Type: text/plain, Size: 3198 bytes --]

Hi Dean,

On Fri, 18 Jul 2025, Dean Marx wrote:

> On Fri, Jul 18, 2025 at 11:05 AM Thomas Wilks <thomas.wilks@arm.com> wrote:
>>
>> Port over the rss_key_update, pmd_rss_reta and pmd_rss_hash
>> test suites from old DTS into one file including all of the
>> helper functions that are required by all of the test suites
>> to work.
>>
>> The rss_key_update test cases verify that setting a new hash
>> key when Receive Side Scaling (RSS) will result in a change
>> in the packets destination queue. These test cases also
>> verifies that the reported key size of the NIC is correct.
>>
>> The pmd_rss_reta test cases verify that Redirection Tables (RETAs)
>> of different sizes function correctly in RSS. These test cases
>> also verify that the reported reta size of the NIC is correct.
>>
>> The pmd_rss_hash test cases verify that the 4 supported types of
>> hashing algorithm used in RSS function correctly and that the nic
>> supports them. The four hashing algorithms being DEFAULT, TOEPLITZ,
>> SYMMETRIC_TOEPLITZ and SIMPLE_XOR. These test cases also verify
>> that the supported hashing algorithms reported by the NIC are correct.
>>
>> Signed-off-by: Alex Chapman <alex.chapman@arm.com>
>> Signed-off-by: Thomas Wilks <thomas.wilks@arm.com>
>
> It was brought up at the DTS meeting yesterday that this suite is
> reliable on Intel NICs, but unreliable on Mellanox (CX6), which I can
> confirm after running on a CX5 and Intel XL710 and seeing the same
> behavior.

As I tried to explain earlier, this might be due to the 'queue' array of the
action 'rss' logically comprising a separate 'reta' for the packets intercepted
by the flow. The test should not check such packets against the global 'reta'.

As to why the test passes for the latter NIC, please take a look at [1]. In that
specific case, the code that is meant to parse the 'queue' array of action 'rss'
might be called only when there are no match items in the flow pattern or when
the first pattern item is VLAN. If this is indeed the case, then the use of
action 'rss' overrides only the hash types for packets intercepted by the flow,
but not the 'reta' to be used, so they still land the global 'reta'.

Also, in 'setup_rss_environment', it might be more robust to first configure the
port's global 'reta' and then insert the flow (if any), to rule out the flow
possibly overriding the global 'reta', which, in theory, shall not happen.

With this in mind, the test could possibly be reworked to act as follows:

1) set up and memorise the port's global 'reta';
2) create a flow rule (say, match UDP DST "A") with 'rss', memorise its 'reta';
4) send a packet that matches the flow (say, with UDP DST "A");
5) receive the packet and check the queue against the flow's own 'reta';
    on queue mismatch, check against the global 'reta' and log the artifact;
6) send a packet that does not match the flow (say, with UDP DST "B");
7) receive the packet and check the queue against the global 'reta'.

[1] https://github.com/DPDK/dpdk/blob/f6e3473724e7ce31103fa0ecad62b282ec8e7090/drivers/net/intel/i40e/i40e_hash.c#L1176

Thank you.

>
> Reviewed-by: Dean Marx <dmarx@iol.unh.edu>
> Tested-by: Dean Marx <dmarx@iol.unh.edu>
>