On Wed, Oct 16, 2024 at 05:26:48PM +0200, Stefano Brivio wrote: [snip]Adding 2-second delays as we have them for NDP doesn't look that bad:$ grep --exclude-dir=demo -rn "dhclient -6" pasta/dhcp:37:ns /sbin/dhclient -6 --no-pid __IFNAME__ passt_in_ns/dhcp:54:guest /sbin/dhclient -6 __IFNAME__ passt/dhcp:51:guest /sbin/dhclient -6 __IFNAME__ perf/passt_tcp:117:guest dhclient -6 -x perf/passt_tcp:118:guest dhclient -6 __IFNAME__ two_guests/basic:40:guest1 /sbin/dhclient -6 __IFNAME1__ two_guests/basic:41:guest2 /sbin/dhclient -6 __IFNAME2__given that we don't need it on dhclient -x, tests would take about 12 seconds longer.Or we could switch to the arp off / nodad / arp on approach for everything, including SLAAC:$ grep --exclude-dir=demo --exclude-dir=mbuto --exclude-dir=distro --exclude-dir=memory -rn "sleep[ $(printf '\t')].*2" pasta/ndp:21:sleep 2 passt_in_ns/icmp:29:ns ip addr add 2001:db8::1 dev __IFNAME_NS__ && sleep 2 # DAD passt/ndp:19:guest ip link set dev __IFNAME__ up && sleep 2 two_guests/basic:39:sleep 2and save slightly less than 8 seconds. If you ask me, I would have a slight preference for the nodad approach.Much as I don't like making the tests slower, I don't think the nodad approach is a good idea. It's fine if we think of the NDP/DHCP only as setting things up for the transfer tests. But they also serve the purpose of testing the NDP and DHCP paths themselves. For that purpose we should perform a full "normal" configuration, including DAD. [e.g. if we really did manage to break our NS responses so that we totally broke DAD, we'd want our tests to catch that]. I have a draft implementation of explicitly waiting for DAD to complete both for SLAAC and for DHCPv6, patches coming shortly. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson