In D38828#884135, @ngie wrote:

The kldload check function seems like it should be in a common function. Also: I might reword the message to state: “This test requires the tarfs kernel module (not available).”

Fixed the crash here:

Need more work

In file included from /usr/src/bin/cat/cat.c:60:
/usr/obj/amd64.amd64/tmp/usr/include/capsicum_helpers.h:42:10: fatal error: 'libcasper.h' file not found
#include <libcasper.h>

I didn't notice any performance impact with this patch (I've applied D37976 and D37977 together).
Lab is measuring the forwarding rate on a very simple IPFW firewall in front of 2 packets generators (one legitimate 20Mpps flows, a second illegimitate 20Mpps flows).

x FreeBSD n280910, packets-per-second forwarded (ipfw-at-nic-level)
+ FreeBSD n280910 with D37976 and D37977, packets-per-second forwarded (ipfw-at-nic-level)
+--------------------------------------------------------------------------+
|   *       x  +      * + x      x                                        +|
|       |___________A_M________|                                           |
||____________________M_____A__________________________|                   |
+--------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5      12683306      12686106      12685002      12684784     1099.0563
+   5      12683316      12689972      12685037      12685578     2566.0973 
No difference proven at 95.0% confidence

Was added into the TCP test suite.

This fix all the error I had with simple make -j 16 clean.
I'm able to run make -j 160 buildworld now without any core generated.

I've removed white spaces found in this script too.

Following new troubleshooting study from zlei.huang@gmail.com on PR, he identified the culprid commits and proposed a simpler way to reproduce it.
The problem isn't with vnet but the IP stack and jai, so rewrote the full tests to a simpler version and move it to the usr.sbin/jail tests.

Thanks for the tips about checking for dying state: This is the root cause is. The jail is stuck forever in dying state after destroying (without even using) the vnet interface.

I'm testing the 3 reviews (D37691, D37692 and D37693) at the same time, at for the first build & test run, regression tests still failing:

• sys.kern.ktls_test.ktls_receive_aes128_cbc_1_1_sha1_bad_major
• sys.kern.ktls_test.ktls_receive_aes256_cbc_1_2_sha256_bad_minor
• sys.kern.ktls_test.ktls_receive_aes256_cbc_1_1_sha1_oversized_record
• sys.kern.ktls_test.ktls_receive_chacha20_poly1305_1_3_oversized_record

I could add this patch to the upcoming new 2.0.11 bird port. This version already includes the merged sysdep/linux/netlink.c and sysdep/cf/bsd-netlink.h (only missing sysdep/bsd-netlink/Makefile).

Update comments following advices

In D36344#826376, @markj wrote:

In D36344#825272, @markj wrote:

I see now. The problem is that pools created by makefs always have the same GUID, so they can't be imported simultaneously. I added a parameter to makefs to specify a PRNG seed, and if I modify the tests to use it, they can run in parallel without problems. So, I don't think it'll be necessary to serialize the makefs_zfs tests.

I tried several variants of this idea but was always able to trigger occasional collisions by running the ZFS tests in a loop overnight. So I ended up just committing a variant of this patch, together with some unrelated bug fixes.

In D36344#825266, @markj wrote:

makefs_zfs regression tests are all using the same zpool name

The poolname contains the PID, so I guess kyua is executing multiple tests in the same process context? How can I see the full test stdout/stderr when running multiple tests in parallel?

In D33658#818854, @melifaro wrote:

@olivier: any chance you could benchmark it?

yes the sleep is racy, but I have no idea to fix it.
Without it, the test will always fails: There is a delay between the jail destruction and the interface being visible back from the host.

Because this kyua limitation, the current trend is to disable parallel tests for the specific suite, and it is fine.

In D35260#799196, @glebius wrote:

Oh, this was somewhat predictable. The one that can't run in parallel is unix_passfd_test:send_and_shutdown. Is it possible to isolate only this one, or whole binary needs to be exclusive?