Add tunable net.iflib.tx_update_freq to set transmit descriptor update frequency

[nc]

Summary

Introduce tunable net.iflib.tx_update_freq to allow an user to set the network transmit descriptor update frequency. Previously, this was hardcoded at 16.

Submitted by: Neel Chauhan <neel AT neelc DOT org>

Test Plan

Compile HEAD and reboot.

Set the tunable net.iflib.tx_update_freq, say net.iflib.tx_update_freq=32 whether by sysctl or /boot/loader.conf.

[koobs]

Might there be ways to make this run-time tunable, or is it fundamentally not possible even in principle?

[nc]

I have a new patch making net.iflib.tx_update_freq a sysctl. I attempted to net.iflib.tx_update_freq=32 from 16 (without rebooting!) and it worked.

Luckily with a brand-new and fast dev box, I could compile and test quickly.

[koobs]

In D24937#560621, @neel_neelc.org wrote:

I have a new patch making net.iflib.tx_update_freq a sysctl. I attempted to net.iflib.tx_update_freq=32 from 16 (without rebooting!) and it worked.

Luckily with a brand-new and fast dev box, I could compile and test quickly.

\o/

Thanks Neel!

[afedorov]

sys/net/iflib.c

2916 ↗

(On Diff #73493)

I am worried that if the user sets the value to 1, then this will lead to division by zero and to kernel panic. I think additional checks are needed.

[gallatin]

sys/net/iflib.c

590

Can you please make this a tunable as well? Eg CTLFLAG_RWTUN

[nc]

Done.

[markj]

sys/net/iflib.c

589

Note, ift_update_freq has type uint8_t.

592

The description is wrong. From my reading of the code, which may be incorrect, this tunable really controls the number of outstanding buffers queued for transmit before we make them visible to the hardware. It also controls the rate at which the hardware will generate interrupts in response to completed transmits. The precise relationship is hard to explain.

2916 ↗

(On Diff #73493)

Well, the division is performed first, so the only value that should cause a panic is 0, but yes, we need a sysctl handler to validate this. The tricky thing is that the set of valid values for ift_update_freq depends on the size of the hardware transmit queues, which of course can vary. So it's not clear to me that a global sysctl really makes sense.