From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:35596 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751455AbeBWRsE (ORCPT ); Fri, 23 Feb 2018 12:48:04 -0500 Date: Fri, 23 Feb 2018 12:48:02 -0500 (EST) Message-Id: <20180223.124802.1669012463834833697.davem@davemloft.net> To: willemdebruijn.kernel@gmail.com Cc: netdev@vger.kernel.org, maloneykernel@gmail.com, willemb@google.com Subject: Re: [PATCH net-next] selftests/net: ignore background traffic in psock_fanout From: David Miller In-Reply-To: <20180223165620.136975-1-willemdebruijn.kernel@gmail.com> References: <20180223165620.136975-1-willemdebruijn.kernel@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Willem de Bruijn Date: Fri, 23 Feb 2018 11:56:20 -0500 > From: Willem de Bruijn > > 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 Applied, thanks Willem. Indeed, not being able to control hashrnd makes determinism in tests like this quite difficult.