No documentation, just my experience, which is why I asked in the
cover for others to test. I can include test results with the next
revision.

Not so much the test results, but the test case.

The reason i added the devlink option was because the network
contained only devices from one vendor. So the OUI in the MAC
addresses was the same, the usable number of bits in the MAC address
being cut in half, in the best case. As a result, there was a lot of
hash collisions. For this special case network, the test mode hash was
better.

If you are also seeing a lot of collisions, it makes me wounder what
your distribution of MAC addresses is.

quoted

quoted

have a performance impact (the data sheet notes this is for testing
only), but it also enables correctness, at least in local testing.

How do you define correctness? Are you using a well defined test?

Why is the devlink parameter not sufficient.

Devlink would indeed be better, but changing hash mode with a
non-empty ATU causes it to be corrupt on read back. Perhaps the
right solution is to flus the ATU when changing hash mode via
devlink.

Flushing the ATU would make sense. It could well be in the system i
was working on, once it was shown to help, the EEPROM contents was set
to configure the ATU hash at hardware boot time, and devlink was not
used in production. The vendor had a bad habit of using the EEPROM.

     Andrew