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.

Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 include/linux/netdevice.h | 7 +++++++
 net/core/dev.c            | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ae269a2e7f4d..acaec0340266 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1281,6 +1281,12 @@ struct netdev_net_notifier {
  *	constraints, and returns the resulting flags. Must not modify
  *	the device state.
  *
+ * void (*ndo_update_offloads)(struct net_device *dev);
+ *	Called during feature update to allow device to compute and update
+ *	offload features (like vlan_features, hw_enc_features) based on
+ *	current lower device configuration. Typically used by master
+ *	devices to aggregate features from slave devices.
+ *
  * int (*ndo_set_features)(struct net_device *dev, netdev_features_t features);
  *	Called to update device configuration to new features. Passed
  *	feature set might be less than what was returned by ndo_fix_features()).
@@ -1558,6 +1564,7 @@ struct net_device_ops {
 							struct sock *sk);
 	netdev_features_t	(*ndo_fix_features)(struct net_device *dev,
 						    netdev_features_t features);
+	void			(*ndo_update_offloads)(struct net_device *dev);
 	int			(*ndo_set_features)(struct net_device *dev,
 						    netdev_features_t features);
 	int			(*ndo_neigh_construct)(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index 200d44883fc1..bbd532aa6a1b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -11011,6 +11011,9 @@ int __netdev_update_features(struct net_device *dev)
 	ASSERT_RTNL();
 	netdev_ops_assert_locked(dev);
 
+	if (dev->netdev_ops->ndo_update_offloads)
+		dev->netdev_ops->ndo_update_offloads(dev);
+
 	features = netdev_get_wanted_features(dev);
 
 	if (dev->netdev_ops->ndo_fix_features)

-- 
Git-155)

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
(2 flags since netdev_compute_master_upper_features takes a bool
argument) that changes __netdev_update_features()'s behavior? Since
the goal for the netdev_compute_master_upper_features() work was to
make this code more common, not introducing a new ndo where random
hacks can accumulate separately in each driver would maybe make more
sense?

-- 
Sabrina

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.

Thanks
Hangbin

> (2 flags since netdev_compute_master_upper_features takes a bool
> argument) that changes __netdev_update_features()'s behavior? Since
> the goal for the netdev_compute_master_upper_features() work was to
> make this code more common, not introducing a new ndo where random
> hacks can accumulate separately in each driver would maybe make more
> sense?
> 
> -- 
> Sabrina

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?

-- 
Sabrina

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