[j-nsp] LAG/ECMP hash performance

[Saku Ytti]

On Thu, 29 Aug 2019 at 22:17, Thomas Bellman <bellman at nsc.liu.se> wrote:

> I don't think anyone has said that any product use the ethernet
> packet's CRC for LAG/ECMP hashing.  Just that they might reuse
> the CRC circuitry in the NPU/ASIC for calculating this hash, but
> based on different inputs.

Exactly and even that isn't true anymore today, since PHY and lookup
are usually different physical chips (still exceptions exist). Reuse
of CRC circuitry for MAC table hashing and LAG hashing does of course
make sense, for some specific constrains, which usually are not today
in modern devices and I think people have just grandfathered old
solution.

Obviously FCS on Ethernet specifically has bias, because it will
detect every single and every double bit flip at 1500B, so it
particularly avoids collisions on small changes. Where hash function
with good diffusion quality would not have such bias and would be
terrible FCS, as at FCS we care more about coverage of small changes
than consider all changes equal importance.
To say it otherwise CRC is great FCS, okish LAG balancer, but ideally
LAG should use hash which has theoretically ideal diffusion and such
hash can be implemented cheaply.

-- 
  ++ytti