On Sat, 05 Sep 2026 22:22:06 -0400 Willem de Bruijn wrote:
quoted
quoted
Perhaps I don't understand how dev->pacing_offload_horizon
would function as a boolean.
The only uses of the new value are:
- as the qdisc bound, replacing the max_ value
-> Leave the qdisc as is, let qdisc config define the active horizon
- in the driver
I see your point now, thanks. A flag NETIF_F_PACING_OFFLOAD?
From the name I suspect you mean a feature / ethtool (-k/-K) ?
That would do, but presumably not as a real low bit within
dev->features ? I guess it is a datapath feature but somehow
those bits feel too precious.
The two configurable offload_horizon fields is definitely redundant.
I do not want to ship idpf with the feature on by default, because of
SO_TXTIME. But a boolean will do.
Plus, a netdevice_notifier in FQ to clear q->offload_horizon
- when this feature flips to off or
Not sure if we should be clearing user config or rejecting
the feature change if currently in use.
- when dev->max_pacing_hardware_offload changes to a value smaller
than then configured q->offload_horizon (e.g., on device reset).