On Dec 1, 2025, at 21:56, Hangbin Liu [off-list ref] wrote:

On Mon, Dec 01, 2025 at 07:01:23PM +0800, Tonghao Zhang wrote:

quoted

quoted

quoted

quoted

I don’t see the benefit of moving NETDEV_NOTIFY_PEERS before NETDEV_BONDING_FAILOVER.
Is there a specific reason or scenario where this ordering change is required?

No, to simplify the code, and use common peer notify reset function.

bond_change_active_slave() is called under RTNL lock. We can use
bond_peer_notify_reset() here. But I don't think there is a need to move
NETDEV_NOTIFY_PEERS before NETDEV_BONDING_FAILOVER.

Is there a dependency relationship between NETDEV_NOTIFY_PEERS and NETDEV_BONDING_FAILOVER?
In vlan, macvlan, ipvlan netdev, NETDEV_NOTIFY_PEERS and NETDEV_BONDING_FAILOVER use the same action.
net/8021q/vlan.c
drivers/net/macvlan.c
drivers/net/ipvlan/ipvlan_main.c

Quote from ad246c992bea ("ipv4, ipv6, bonding: Restore control over number of peer notifications")

"""
   For backward compatibility, we should retain the module parameters and
   sysfs attributes to control the number of peer notifications
   (gratuitous ARPs and unsolicited NAs) sent after bonding failover.
"""

In theory we should send notify after failover. The infiniband driver also
has specific functions to handle NETDEV_BONDING_FAILOVER. I'm not sure if the
miss-order affect it. Maybe Jay knows more.

Hi Jay,
any idea about the order NETDEV_NOTIFY_PEERS and NETDEV_BONDING_FAILOVER? It seems that there is no dependency between them in infiniband driver.

Thanks
Hangbin