[PATCH net-next v3 0/5] net: centralize master device offload feature computation

Hangbin Liu posted 5 patches 3 weeks ago
drivers/net/bonding/bond_main.c | 13 ++++----
drivers/net/macsec.c            | 23 +++++++-------
drivers/net/net_failover.c      | 66 +++++------------------------------------
drivers/net/team/team_core.c    | 14 ++++-----
include/linux/netdevice.h       |  7 +++++
include/net/net_failover.h      |  7 -----
net/8021q/vlan.c                |  2 --
net/bridge/br_device.c          |  6 ++++
net/bridge/br_if.c              |  6 ----
net/core/dev.c                  | 11 +++++--
net/hsr/hsr_slave.c             |  1 -
11 files changed, 55 insertions(+), 101 deletions(-)
[PATCH net-next v3 0/5] net: centralize master device offload feature computation
Posted by Hangbin Liu 3 weeks ago
Currently, master devices (bonding, bridge, team) manually call
netdev_compute_master_upper_features() scattered throughout their port
add/remove operations. This approach requires each driver to remember
to update features at the right times and leads to code duplication.

The series adds a new ndo_update_offloads callback that is automatically
invoked during feature updates when upper/lower device relationships change.
This centralizes the feature computation flow and removes the burden
from individual drivers.

---
Changes in v3:
- ndo_set_features may be skipped when no feature change, fallback to
  use ndo_update_offloads for offload computation (Simon Horman)
- Link to v2: https://lore.kernel.org/r/20260313-offload_compute-v2-0-ffbc8ce5d50c@gmail.com

Changes in v2:
- Fix macsec Security Entity uninitialized issue (Sabrina Dubroca)
  - Tested with macsec-offload.sh, rtnetlink.sh, link_netns.py, all pssed
- Link to v1: https://lore.kernel.org/r/20260310-offload_compute-v1-0-3df79c09ea65@gmail.com

---
Hangbin Liu (5):
      net: add ndo_update_offloads for offload computation
      net: use ndo_update_offloads to set offload features for bonding/bridge/team
      macsec: move netdev_upper_dev_link() after macsec_changelink_common()
      failover: use ndo_update_offloads for failover offload compute
      net: no need to disable LRO specifically

 drivers/net/bonding/bond_main.c | 13 ++++----
 drivers/net/macsec.c            | 23 +++++++-------
 drivers/net/net_failover.c      | 66 +++++------------------------------------
 drivers/net/team/team_core.c    | 14 ++++-----
 include/linux/netdevice.h       |  7 +++++
 include/net/net_failover.h      |  7 -----
 net/8021q/vlan.c                |  2 --
 net/bridge/br_device.c          |  6 ++++
 net/bridge/br_if.c              |  6 ----
 net/core/dev.c                  | 11 +++++--
 net/hsr/hsr_slave.c             |  1 -
 11 files changed, 55 insertions(+), 101 deletions(-)
---
base-commit: 5446b8691eb8278f10deca92048fad84ffd1e4d5
change-id: 20260310-offload_compute-4c0bafa2e022

Best regards,
-- 
Hangbin Liu <liuhangbin@gmail.com>
Re: [PATCH net-next v3 0/5] net: centralize master device offload feature computation
Posted by Paolo Abeni 2 weeks, 4 days ago
On 3/16/26 5:26 AM, Hangbin Liu wrote:
> Currently, master devices (bonding, bridge, team) manually call
> netdev_compute_master_upper_features() scattered throughout their port
> add/remove operations. This approach requires each driver to remember
> to update features at the right times and leads to code duplication.
> 
> The series adds a new ndo_update_offloads callback that is automatically
> invoked during feature updates when upper/lower device relationships change.
> This centralizes the feature computation flow and removes the burden
> from individual drivers.

I'm sorry for the late feedback, but I think the driver cleanup and
simplification is not worthy the core complexity and the new NDO added.

The AI reported issue would probably need very non trivial changes to
both team and bond driver to be addressed.

Most of the cleanups belong to netdev_compute_master_upper_features()
introduction in the failover driver. Factoring out that single change
would be IMHO a better option, if possible.

The new ndo looks controversial. We already have 2 different ndo at
__netdev_update_features() time, with slightly different semantic.
Adding another one feels like a design issue.

/P
Re: [PATCH net-next v3 0/5] net: centralize master device offload feature computation
Posted by Jakub Kicinski 2 weeks, 4 days ago
On Thu, 19 Mar 2026 10:52:34 +0100 Paolo Abeni wrote:
> On 3/16/26 5:26 AM, Hangbin Liu wrote:
> > Currently, master devices (bonding, bridge, team) manually call
> > netdev_compute_master_upper_features() scattered throughout their port
> > add/remove operations. This approach requires each driver to remember
> > to update features at the right times and leads to code duplication.
> > 
> > The series adds a new ndo_update_offloads callback that is automatically
> > invoked during feature updates when upper/lower device relationships change.
> > This centralizes the feature computation flow and removes the burden
> > from individual drivers.  
> 
> I'm sorry for the late feedback, but I think the driver cleanup and
> simplification is not worthy the core complexity and the new NDO added.

+1 FWIW, I didn't want to be negative but I felt the same way..
We are always one step away from an inf loop propagating the features
it's a delicate space :S
Re: [PATCH net-next v3 0/5] net: centralize master device offload feature computation
Posted by Hangbin Liu 2 weeks, 4 days ago
On Thu, Mar 19, 2026 at 10:52:34AM +0100, Paolo Abeni wrote:
> I'm sorry for the late feedback, but I think the driver cleanup and
> simplification is not worthy the core complexity and the new NDO added.
> 
> The AI reported issue would probably need very non trivial changes to
> both team and bond driver to be addressed.
> 
> Most of the cleanups belong to netdev_compute_master_upper_features()
> introduction in the failover driver. Factoring out that single change
> would be IMHO a better option, if possible.
> 
> The new ndo looks controversial. We already have 2 different ndo at
> __netdev_update_features() time, with slightly different semantic.
> Adding another one feels like a design issue.

Thanks, I will check if we can call netdev_compute_master_upper_features()
in failover driver directly.

Hangbin