Re: [PATCH net-next v14 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

[Hangbin Liu <liuhangbin@gmail.com>]

On Wed, Oct 22, 2025 at 05:50:33PM -0700, Jakub Kicinski wrote:
> On Wed, 22 Oct 2025 11:25:27 -0700 David Wilder wrote:
> > The current implementation of the arp monitor builds a list of vlan-tags by
> > following the chain of net_devices above the bond. See bond_verify_device_path().
> > Unfortunately, with some configurations, this is not possible. One example is
> > when an ovs switch is configured above the bond.
> 
> Once again if anyone thinks this belongs in the kernel please speak up.
> Otherwise let this be the last posting.
> 
> *If* someone does speak up in support you will need to find a less ugly
> way to represent the attribute within Netlink. What you invent must work
> in YNL and be added to the spec (Documentation/netlink/specs/rt-link.yaml)

Hi David,

I haven’t tested it yet, but for the netlink part, instead of using a
randomly sized binary structure, maybe you could try using nested attributes.
For example:

IFLA_BOND_ARP_IP_TARGET (nested)
 ├── [0] = 192.168.1.1              old format (no VLAN)
 ├── [1] (nested)                   new format (with VLAN tags)
 │     ├── IFLA_BOND_ARP_TARGET_IP = 192.168.2.1
 │     └── IFLA_BOND_ARP_TARGET_VLANS (nested)
 │           ├── [0] = 10
 │           ├── [1] = 20
 │           └── [2] = 30
 ├── [2] (nested)                   new format (no VLAN tags: leave empty or use nla_put_empty_nest())
 │     └── IFLA_BOND_ARP_TARGET_IP = 192.168.3.1

When parsing the attributes, first check if the data is nested using:
nla_type(attr) & NLA_F_NESTED. If not, just copy the IPv4 addresses.

If it’s nested, handle the target IP and VLANs accordingly.
The downside is that this approach would introduce three levels of nesting,
which might not be ideal.

Thanks
Hangbin