From: Willem de Bruijn <willemdebruijn.ker...@gmail.com> Date: Fri, 23 Feb 2018 11:56:20 -0500
> From: Willem de Bruijn <will...@google.com> > > The packet fanout test generates UDP traffic and reads this with > a pair of packet sockets, testing the various fanout algorithms. > > Avoid non-determinism from reading unrelated background traffic. > Fanout decisions are made before unrelated packets can be dropped with > a filter, so that is an insufficient strategy [*]. Run the packet > socket tests in a network namespace, similar to msg_zerocopy. > > It it still good practice to install a filter on a packet socket > before accepting traffic. Because this is example code, demonstrate > that pattern. Open the socket initially bound to no protocol, install > a filter, and only then bind to ETH_P_IP. > > Another source of non-determinism is hash collisions in FANOUT_HASH. > The hash function used to select a socket in the fanout group includes > the pseudorandom number hashrnd, which is not visible from userspace. > To work around this, the test tries to find a pair of UDP source ports > that do not collide. It gives up too soon (5 times, every 32 runs) and > output is confusing. Increase tries to 20 and revise the error msg. > > [*] another approach would be to add a third socket to the fanout > group and direct all unexpected traffic here. This is possible > only when reimplementing methods like RR or HASH alongside this > extra catch-all bucket, using the BPF fanout method. > > Signed-off-by: Willem de Bruijn <will...@google.com> Applied, thanks Willem. Indeed, not being able to control hashrnd makes determinism in tests like this quite difficult.
