Re: [PATCH net-next 0/2] mv88e6xxx: Allow config of ATU hash algorithm

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Oct 04, 2019 at 11:44:02AM +0300, Vladimir Oltean wrote:
> Hi Andrew,
> 
> On Fri, 4 Oct 2019 at 10:55, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > The Marvell switches allow the hash algorithm for MAC addresses in the
> > address translation unit to be configured. Add support to the DSA core
> > to allow DSA drivers to make use of devlink parameters, and allow the
> > ATU hash to be get/set via such a parameter.
> >
> 
> What is the hash algorithm used by mv88e6xxx? In sja1105 it is simply
> crc32 over the {DMAC, VLAN} key, with a configurable polynomial
> (stored in Koopman notation, but that is maybe irrelevant).
> Are you really changing the algorithm, but only the hashing function's seed?
> If the sja1105 is in any way similar to mv88e6xxx, maybe it would make
> sense to devise a more generic devlink attribute?
> Also, I believe the hashing function is only relevant if the ATU's CAM
> is set- (not fully-) associative. Then it would make sense to maybe
> let the user know what the total number of FDB entries and buckets is?
> I am not clear even after looking at the mv88e6xxx_g1_atu_* functions.
> How would they know they need to change the hash function, and what to
> change it to?

Hi Vladimir

I have a second patchset which gives you an idea of the fill level. It
is documented that there are 4 buckets, and you can get the number of
buckets which are used at each level. The patch will also give the
total number of ATU entries.

The datasheet does not specify how the hashing is performed, just that
there are 4 possible configurations. We founds that the default
configuration does not work too well when all the equipment is from
one vendor, so the OUI is the same. By changing the algorithm we got a
better spread. Maybe it is giving more weight to the lower bits of the
MAC address?

Given the level of undocumented black magic, i don't know if we can do
a more generic configuration.

  Andrew