[ovs-dev] [v4 02/12] dpif-netdev: Add auto validation function for miniflow extract

[Eelco Chaudron]

On 1 Jul 2021, at 19:24, Van Haaren, Harry wrote:

>> -----Original Message-----
>> From: Eelco Chaudron <echaudro at redhat.com>
>> Sent: Thursday, July 1, 2021 5:19 PM
>> To: Van Haaren, Harry <harry.van.haaren at intel.com>
>> Cc: Amber, Kumar <kumar.amber at intel.com>; dev at openvswitch.org;
>> i.maximets at ovn.org; Flavio Leitner <fbl at sysclose.org>; Stokes, Ian
>> <ian.stokes at intel.com>
>> Subject: Re: [ovs-dev] [v4 02/12] dpif-netdev: Add auto validation function for
>> miniflow extract
>>
>>
>>
>> On 29 Jun 2021, at 13:05, Van Haaren, Harry wrote:
>>
>>> Hi Eelco,
>>>
>>> Would you describe the actual test being run below?
>>>
>>> I'm having a hard time figuring out what the actual datapath packet flow is. It
>> seems strange
>>> that MFEX optimizations are affected by flow-count, that doesn't really logically
>> make sense.
>>> Hence, some more understanding on what the test setup is may help.
>>>
>>> To remove complexity & noise from the setup: does running a simple Phy-to-Phy
>> test with L2 bridging
>>> cause any perf degradation? If so, please describe that exact setup and I'll try to
>> reproduce/replicate results here.
>>>
>>
>> I did run some more tests both PVP as well as a physical port loopback, i.e. same
>> port in and out (so without the VM).
>> Here are some results (I did 5 runs and took the average, and mention the RS
>> deviation for all runs to make sure it not that):
>
> Ah, thanks for checking noisiness of data, indeed that was going to be my next question!
>
>
>> +-----------------------+-----------------+-------------+--------+---------+--------+--------+-----
>> ---+---------+--------+-----+-------+------+-------+------+-------+
>> | P (loopback)          |                 | Packet size |        |         |        |        |        |         |        |
>> |       |      |       |      |       |
>> |                       | Number of flows | 64          |        |     128 |        |    256 |        |     512 |
>> | 768 |       | 1024 |       | 1514 |       |
>> | without vs with patch | 1000            | -81863      | -0.98% | -134888 | -1.55% | -
>> 66261 | -0.80% | -110552 | -1.35% |   0 | 0.00% |    0 | 0.00% |    0 | 0.00% |
>> | RS Deviation          |                 |             |  0.09% |         |  0.46% |        |  0.09% |         |
>> 0.06% |     | 0.00% |      | 0.00% |      | 0.00% |
>> | without vs with patch | 10000           | -58903      | -0.82% |  -52742 | -0.73% | -
>> 46875 | -0.64% |  -49871 | -0.68% |   0 | 0.00% |    0 | 0.00% |    0 | 0.00% |
>> | RS Deviation          |                 |             |  0.24% |         |  0.13% |        |  0.13% |         |
>> 0.10% |     | 0.00% |      | 0.00% |      | 0.00% |
>> +-----------------------+-----------------+-------------+--------+---------+--------+--------+-----
>> ---+---------+--------+-----+-------+------+-------+------+-------+
>
> Thanks, so I'm reading that as showing 64 bytes negative 1%, 128 byte pkts -2%.
> Small deltas, but in the wrong direction, thanks for reporting.
>
>> I’ll share the google sheet with you directly as it also has the config, and PVP results.
>
> I can't actually access that doc, sorry. Results above are enough to go by for now :)

It’s attached.

> We can investigate if there's any optimizations to be done to improve the scalar DPIF
> enabling of the miniflow extract func ptr, but I'm not sure there is.
>
> If we cannot improve the perf data from above, there is an option to not enable the scalar
> DPIF with the AVX512 MFEX optimizations. (Logic being if AVX512 is present, running both
> the DPIF + MFEX makes sense). What do you think?

This is on a system without AVX512 support, so all is disabled. The “without patch” has both the new AVX patches removed (mfex and dpif framework).

>
>> //Eelco
>
> Note I'm out of office tomorrow Friday 2nd July, so expect replies early next week.
> Regards, -Harry