Re: [PATCH net-next v3 1/5] net: add ndo_update_offloads for offload computation

On Thu, Mar 19, 2026 at 12:29:25AM +0100, Sabrina Dubroca wrote:
> 2026-03-18, 01:15:20 +0000, Hangbin Liu wrote:
> > On Tue, Mar 17, 2026 at 04:14:35PM +0100, Sabrina Dubroca wrote:
> > > 2026-03-16, 12:26:09 +0800, Hangbin Liu wrote:
> > > > Add a new ndo_update_offloads callback to net_device_ops that allows
> > > > devices to compute and update their offload features during feature
> > > > updates.
> > > > 
> > > > This callback enables master devices to recompute their features
> > > > based on current slave device configuration. This is particularly
> > > > useful for bonding, bridging, team, and failover devices that need
> > > > to aggregate features from their lower devices.
> > > > 
> > > > The callback is optional and only implemented by devices that need
> > > > dynamic offload feature computation.
> > > 
> > > Maybe a dumb idea (and sorry to suggest this quite late in your
> > > submissions): since all implementations of this callback are only
> > > calling netdev_compute_master_upper_features(), does this need to be a
> > > new ndo, or could this be some kind of flag within struct net_device
> > 
> > Ideally all dev with IFF_MASTER should re-compute the offload. But at present
> > some master devices do have this flag, or have their own offload
> > implementation.
> > 
> > Do you mean add a new private flag, like IFF_RECOMPUTE_OFFLOAD? For the second
> > parameter, maybe we can pass false for bridge specifically.
> 
> I hadn't thought specifically about where to store that flag. As a
> private flag, why not (this should be internal to the kernel, so not a
> uapi flag like IFF_MASTER), but priv_flags is marked as "hotpath" now,
> so maybe something similar to needs_free_netdev or
> netns_immutable. Either way, then devices are free to do their own
> magic, or request the core to call
> netdev_compute_master_upper_features() for them in some common
> locations. Does that makes sense?

This looks better than private flags. I just feel this magic hide a little
deep for a common master feature.

Thanks
Hangbin