PSA: 3-argument get_hash method

[vgurevich]

The current PSA definition for hash extern includes the "P4_14-compatible" method

  O get_hash<T, D>(in T base, in D data, in T max);

in addition to

  O get_hash<D>(in D data);

Given that we had some discussions about the "max" value and concluded that most probably it will be restricted to powers of two, I wonder if we really need this method, since the type "O" will do the same thing anyway and one can always add the base using a simple "+".

If, on the other hand, we do not want to limit "max" to just powers of two, then why not define a clear "modulo" operation?

[jafingerhut]

I have no problem adding to the PSA spec that an implementation need not support modulo values other than powers of 2.

If we leave the parameters that let one specify modulo values that don't fit that restriction in the PSA, it makes it that much easier for an implementation that wants to support other values -- they don't have to create a non-PSA extension to the API, and people's programs are potentially a little bit more portable among implementations that support the more general parameter values.

[ChrisDodd]

Shouldn't targets that support modulo just use %? That already exists in the language, albeit with the note that some targets may not support it. The use of complex primitives with many arguments is a holdover from P4_14 which did not support general expressions.

[jafingerhut]

I suppose they could. It seems that the modulo behavior has been 'bundled' with hash and random behavior for a while in P4, which I can understand perfectly, since hash & modulo is a building block in things like ECMP/LAG member selection in many networking devices, and having modulo bundled with random generation is useful for getting a non-power-of-2 range of random values out.

If we 'unbundle' this, I would point out that I believe modulo is currently only supported for compile time constant values in p4c.