On Sun, 14 Apr 2024 13:04:46 -0400 Willem de Bruijn wrote: > 1. Cleaning up remote state in all conditions, including timeout/kill. > > Some tests require a setup phase before the test, and a matching > cleanup phase. If any of the configured state is variable (even > just a randomized filepath) this needs to be communicated to the > cleanup phase. The remote filepath is handled well here. But if > a test needs per-test setup? Say, change MTU or an Ethtool feature. > Multiple related tests may want to share a setup/cleanup. > > Related: some tests may need benefit from a lightweight stateless > check phase to detect preconditions before committing to any setup. > Again, say an Ethtool feature like rx-gro-hw, or AF_XDP metadata rx. I think this falls into the "frameworking debate" we were having with Petr. The consensus seems to be to keep things as simple as possible. If we see that tests are poorly written and would benefit from extra structure we should try impose some, but every local custom is something people will have to learn. timeout/kill is provided to us already by the kselftest harness. > 2. Synchronizing peers. Often both peers need to be started at the > same time, but then the client may need to wait until the server > is listening. Paolo added a nice local script to detect a listening > socket with sockstat. Less of a problem with TCP tests than UDP or > raw packet tests. Yes, definitely. We should probably add that with the first test that needs it.
