On Mon, 10 Feb 2020 17:04:10 +0100 Florian Westphal <fw@xxxxxxxxx> wrote: > Stefano Brivio <sbrivio@xxxxxxxxxx> wrote: > > On Fri, 7 Feb 2020 11:34:42 +0100 > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > > On Thu, Jan 30, 2020 at 01:16:58AM +0100, Stefano Brivio wrote: > > > > This test checks that set elements can be added, deleted, that > > > > addition and deletion are refused when appropriate, that entries > > > > time out properly, and that they can be fetched by matching values > > > > in the given ranges. > > > > > > I'll keep this back so Phil doesn't have to do some knitting work > > > meanwhile the tests finishes for those 3 minutes. > > > > But I wanted to see his production :( > > > > > If this can be shortened, better. Probably you can add a parameter to > > > enable the extra torture test mode not that is away from the > > > ./run-test.sh path. > > > > I can't think of an easy way to remove that sleep(1), I could decrease > > the timeouts passed to nft but then there's no portable way to wait for > > less than one second. > > Even busybox' sleep can do 'sleep 0.01' Wait, that's only if you build it with ENABLE_FEATURE_FANCY_SLEEP and ENABLE_FLOAT_DURATION. > do we really need to be *that* portable? I don't actually know :) However, with Phil's idea: On Mon, 10 Feb 2020 16:51:47 +0100 Phil Sutter <phil@xxxxxx> wrote: > You could test the timeout feature just once and for all? I doubt there > will ever be a bug in that feature which only a certain data type > exposes, but you may e.g. create all the sets with elements at the same > time so waiting for the timeout once is enough. which I think is entirely reasonable, this becomes a single one-second sleep, so it shouldn't be a problem anymore. I would propose that I try this first, see if it gets reasonable, if it's not enough I'd go on and just reduce the number of combinations depending on how the script is invoked. -- Stefano
