define a way to limit mbuf cluster allocations to n in a code section

Why is this necessary? Why can't we let the driver allocate all available mbufs?

Because we want to avoid a situation where we exhaust all of our preallocated mbufs to fill populate a single ring. That's the reason we preallocate as much as we do today.

How do multi-queue NICs behave when some rx rings are empty? If a packet arrives on an empty rx ring, does the packet get dropped, or does it get queued to a different rx ring?

I've always assumed that the packet would get dropped if the ring to which it's steered doesn't have any available buffer space. That might not be true for all devices, but I wouldn't want to rely on that.

I like your plan overall. I'm not intimately familiar with the network drivers, so I can't comment on that aspect.

I don't get why we don't send PC and the watch stop reason in the '?' case

Ingo will commit something similar in the near future, and Baptiste will import a new release of mandoc. For now, Bapt approved this commit.

Have you proposed this patch to upstream? ingo@openbsd.org is very responsive and should reply back quickly, before adding any custom patch I prefer it to be discussed with upstream first. (don't hesitate to CC me)

Phabricator did not quite do what I wanted. There are two diffs here: formatted pages, and code. See the History tab.

Pages formatted with the old and new code.

In D35187#797770, @markj wrote:

Seems rather bizarre not to use wait() to begin with. I can't see a reason why it was done this way. :/

• Review feedback, and more

D34450 and D34451 fix the WAIT flags in two callers.

In D34452#780985, @vangyzen wrote:

I also noticed that uma_zalloc_domain() does not call uma_zalloc_debug() in the multi-domain path.

• move to uma_zalloc_debug()

This should go in uma_zalloc_debug() instead. Otherwise uma_zalloc_smr() isn't checked.

Thanks for the review, Ryan.

• reword with markj

• auto alloc the struct

Because of this bug, the nfs VFS module was incorrectly unloaded. However, the nfscl module still refused to unload, so the result was mostly harmless, meaning the kernel didn't panic. The worst effect was, NFS was no longer listed as a VFS, so no NFS mounts could be created until the next reboot. Amusingly, kldload failed with EOPNOTSUPP before and after the fix, so I had to use dtrace to see the difference.