Jakub Kicinski wrote: > On Sun, 14 Apr 2024 12:45:43 -0400 Willem de Bruijn wrote: > > Overall, this is really cool stuff (obviously)! > > > > REMOTE instead of EP? > > If I have to (: > Endpoint isn't great. > But remote doesn't seem much better, and it doesn't have a nice > abbreviation :( It pairs well with local. Since in some tests the (local) machine under test is the sender and in others it is the receiver, we cannot use SERVER/CLIENT or so. > > Apparently I missed the earlier discussion. Would it also be possible > > to have both sides be remote. Where the test runner might run on the > > build host, but the kernel under test is run on two test machines. > > > > To a certain extent, same for having two equivalent child network > > namespaces isolated from the runner's environment. > > I was thinking about it (and even wrote one large test which uses > 2 namespaces [1]). But I could not convince myself that the added > complication is worth it. > > [1] https://github.com/kuba-moo/linux/blob/psp/tools/net/ynl/psp.py > > Local namespace testing is one thing, entering the namespace from > python and using the right process abstraction to make sure garbage > collector doesn't collect the namespace before the test exits it > (sigh) is all doable. But we lose the ability interact with the local > system directly when the endpoint is remote. No local FW access with > read/write, we have to "cat" and "echo" like in bash. No YNL access, > unless we ship specs and CLI over. In cases like testing jumbo frames (or other MTU, like 4K), configuration changes will have to be made on both the machine under test and the remote traffic generator/sink. It seems to me unavoidable. Most of the two-machine tests I require an equal amount of setup on both sides. But again, cart before the horse. We can always revisit this later if needed. > So I concluded that we're better off leaning on kselftest for > remote/remote. make install, copy the tests over, run them remotely. > I may be biased tho, I don't have much use for remote/remote in my > development env. > > > Use FC00::/7 ULA addresses? > > Doesn't ULA have some magic address selection rules which IETF > is just trying to fix now? IIUC 0100:: is the documentation prefix, > so shouldn't be too bad? RFC 6666 defines this as the "Discard Prefix".
