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.