proc: Add a network transmit batch pointer to struct thread

[rcm]

Summary

proc: Add a network transmit batch pointer to struct thread

A proposed change to iflib (D60416) rings a transmit queue's doorbell
once per receive pass instead of once per packet. The transmit path,
several calls down the stack from the receive task, has to find the
batch of the thread it runs on. A pointer in struct thread does that
with one load and without per-CPU state or pinning; the batch itself
lives on the receive task's stack for the length of its pass.

Update the KBI assertions and bump __FreeBSD_version.

Sponsored by: Rubicon Communications, LLC ("Netgate")

[kib]

Since this is driver-specific, did you considered using osd(9) osd_register(OSD_THREAD)? [I do not object against adding a thread-local pointer, just want to check other possibilities before]

[rcm]

In D60756#1393605, @kib wrote:

Since this is driver-specific, did you considered using osd(9) osd_register(OSD_THREAD)? [I do not object against adding a thread-local pointer, just want to check other possibilities before]

Yea I did. It is a tad bit slower (~1% w/ pf disabled) based on what I can measure than the thread-local pointer form and it has more failure modes (will need to handle ENOMEM) that will need to be reasoned through. The first set on a thread allocates with M_NOWAIT, so a pass that can't get its slots just won't batch; that seems okay. I did find an issue that probably should be resolved with osd(9) before we consider it as an option. I have posted D60772 that resolves that. The osd(9) form adds something like 50-70 instructions to the hot path. Once pf is enabled though this cost is lost in the noise floor (mostly due to pf stalling on DRAM loads).

So osd(9) is definitely an option. I don't have strong opinions either way we cut it.