On 2/19/2020 8:04 PM, Mark Zhang wrote:
On 2/20/2020 1:41 AM, Tom Talpey wrote:
On 2/19/2020 8:06 AM, Jason Gunthorpe wrote:
On Wed, Feb 19, 2020 at 02:06:28AM +0000, Mark Zhang wrote:
The symmetry is important when calculate flow_label with DstQPn/SrcQPn
for non-RDMA CM Service ID (check the first mail), so that the server
and client will have same flow_label and udp_sport. But looks like it is
not important in this case.
If the application needs a certain flow label it should not rely on
auto-generation, IMHO.
I expect most networks will not be reversible anyhow, even with the
same flow label?
These are network flow labels, not under application control. If they
are under application control, that's a security issue.
As Jason said application is able to control it in ipv6. Besides
application is also able to control it for non-RDMA CM Service ID in ipv4.
Ok, well I guess that's a separate issue, let's not rathole on
it here then.
Hi Jason, same flow label get same UDP source port, with same UDP source
port (along with same sIP/dIP/sPort), are networks reversible?
But I agree, if the symmetric behavior is not needed, it should be
ignored and a better (more uniformly distributed) hash should be chosen.
I definitely like the simplicity and perfect flatness of the newly
proposed (src * 31) + dst. But that "31" causes overflow into bit 21,
doesn't it? (31 * 0xffff == 0x1f0000) >
I think overflow doesn't matter? We have overflow anyway if
multiplicative is used.
Hmm, it does seem to matter because dropping bits tilts the
distribution curve. Plugging ((src * 31) + dst) & 0xFFFFF into
my little test shows some odd behaviors. It starts out flat,
then the collisions start to rise around 49000, leveling out
at 65000 to a value roughly double the initial one (528 -> 1056).
It sits there until 525700, where it falls back to the start
value (528). I don't think this is optimal :-)
Tom.
