RE: [EXTERNAL] Re: [PATCH] hv_netvsc: Set device flags for properly indicating bonding

[Long Li]

> Subject: [EXTERNAL] Re: [PATCH] hv_netvsc: Set device flags for properly
> indicating bonding
> 
> On Wed, 27 Nov 2024 11:42:50 -0800
> longli@xxxxxxxxxxxxxxxxx wrote:
> 
> > hv_netvsc uses a subset of bonding features in that the master always
> > has only one active slave. But it never properly setup those flags.
> >
> > Other kernel APIs (e.g those in "include/linux/netdevice.h") check for
> > IFF_MASTER, IFF_SLAVE and IFF_BONDING for determing if those are used
> > in a master/slave setup. RDMA uses those APIs extensively when looking
> > for master/slave devices.
> >
> > Make hv_netvsc properly setup those flags.
> >
> > Signed-off-by: Long Li <longli@xxxxxxxxxxxxx>
> 
> Linux networking has evolved a patch work of flags to network devices but never
> really standardized on a way to express linked relationships between network
> devices. There are several drivers do this in slighlty different and overlapping
> ways: bonding, team, failover, hyperv, bridge and others.
> 
> The current convention is to mark the primary device as IFF_MASTER and each
> secondary device with IFF_SLAVE.  But not clear what the right combination is if
> stacked more than one level.  Also, not clear if userspace and other addressing
> should use or not use nested devices.
> 
> It would be ideal to deprecate and use different terms than the non-inclusive
> terms master/slave but probably that would have to have been done years ago
> (like 2.5).
> 
> For now, it makes sense for all the nested devices to use IFF_MASTER and
> IFF_SLAVE consistently. It is not a good idea to set the priv_flag for IFF_BONDING
> (or any of the other bits) which should be reserved for one driver.
> 
> If hyperv driver needs to it could add its own flag in netdev_priv_flags, but it looks
> like that is running out of bits. May need to grow to 64 bits or do some more work
> to add a new field for device type. I.e. there are combinations of flags that are
> impossible and having one bit per type leads to a problem. Fixing that is non trivial
> but not impossible level of effort.
> 
> My thoughts, but I don't use or work on Hyper-v anymore.

Thank you. I have sent v2.

Long