Re: [PATCH net-next v8 1/6] net: rtnetlink: add pacing_offload_horizon attribute to net_device

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 8 Sep 2026 16:48:03 -0400 Willem de Bruijn wrote:
> > > 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.  
> >
> > Makes sense.
> >
> > An ethtool -K that does not use dev->features seems like a hack.

It's just a way of avoiding netdev_features_t becoming larger than 64b.
At the uAPI level we have a bitmap so we can express any number of bits.
But in the kernel dev->features is u64 / ull so if we run out of bits
the refactor will be rather painful.

Is it really that much worse to add the support for "high feature bits"
which don't go thru netdev_features_t to ethtool, than sprinkling extra
one off booleans into already bloated RTM_SETLINK? Not sure.

> > Keep the existing ip link attribute and make that settable only to
> > zero or max_pacing_offload_horizon?  
> 
> I've updated to a simple boolean pacing_offload in ip link.
> Let me know if you had something else specific in mind.
> 
> +++ b/Documentation/netlink/specs/rt-link.yaml
> @@ -1089,6 +1089,10 @@ attribute-sets:
> +      -
> +        name: pacing-offload
> +        type: u8

Netlink pads very value to 4B so just make it a u32

> +        doc: Enable EDT pacing offload (0 - disabled, 1 - enabled).

> > > Not sure if we should be clearing user config or rejecting
> > > the feature change if currently in use.  
> >
> > We cannot reject the feature change

Feature change means user requesting the feature to be disabled.

> > if it's a device reset and on re-negotiation the device capability
> > changed. E.g., from a firmware rollout.  
> 
> I added a separate patch that adds a netdevice notifier to FQ.
> To reset offload_horizon on device feature change if needed.
> Or any qdisc feature that depends on device state in principle.

I hate both notifiers everywhere and the idea that we have to be able
to quietly revoke device features "on firmware rollout". It leads to
unmaintainable code which almost never runs so it's buggy half of the
time. Whatever.