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. 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. > Tom.
