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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 09 Sep 2026 11:47:13 -0400 Willem de Bruijn wrote:
> > No different than a loose bit in SETLINK?  
>
> At least then there is no expectation of netdev_features_t behavior.

I'm not sure what "netdev_features_t behavior" is, different "types"
of features behave differently.

> > What I was wondering is - we don't want to implement full handling for
> > high feature bits, agreed, it doesn't seem needed today. But is it
> > better to add such a bit in ethtool regardless, even tho it doesn't get
> > any infra for propagation to uppers etc. Or is it better to start adding
> > one-off bits in rt-link.
> > 
> > Think about it some more, since the max-horizon attr is already in
> > rt-link I guess putting this bit in rt-link does make more sense.  
> 
> Ok, I'll leave this in rt-link then.
> 
> Even then, running out of feature bits will come back to haunt us
> soon enough. A good idea to look into it some more now.
> 
> The main issue here is not wanting to grow netdev_features_t for
> hot cachelines, right? Which besides growing dev->features has a
> cascading effect on all the other fields of that type in net_device
> too.
> 
> Extending struct net_device itself is fine, as long as it happens in
> some cold cacheline at the end.
> 
> Perhaps something like what Paolo did for virtio features in the
> series of 3b17aa13015c ("virtio_net: add supports for extended
> offloads"). With non-contiguous bitmap fields. Everything beyond 64
> is mapped to a new field at the end of the struct. A thin API to
> avoid open-coding that check everywhere. And selective conversion
> only of code/drivers that need to access the extended features.

Trying to code this up may reveal the correct shape of the solution.
My mental model so far has been that features are still a mix of
high touch datapath bits and random config stuff like LOOPBACK or HW_TC
which could as well live in a cold cacheline. So my thinking was that
the first step would be to divorce the internal kernel formats from
uAPI.