> These addresses could be listed with 'bridge fdb' (RTM_GETNEIGH on AF_BRIDGE). > Instead of having a new message to get the missing info (users), maybe it > would > be better to update the current API.
I looked at the FDB dump based on the suggestion and I don't think that path works well. The missing users count is not the only problem: It doesn't list dev->mc for every device. Only ndo_dflt_fdb_dump() walks dev->mc, and rtnl_fdb_dump() calls it only for Ethernet devices that have no ndo_fdb_dump of their own. So bridge, vxlan, macvlan and IPoIB devices never show their multicast filter in "bridge fdb show", while /proc/net/dev_mcast lists them. Fixing that means calling the default dump for those devices too, which adds new entries to "bridge fdb show" output on every one of them. User space can't reliably tell the entries apart either. "ip maddr" would keep NTF_SELF entries with a multicast lladdr, but it seems vxlan's own FDB entries seems also carry NTF_SELF, so a multicast MAC added there as a forwarding rule (bridge fdb add ... dev vxlan0 dst ...) would show up as a device multicast address, while the real dev->mc of that vxlan device is missing. And since a dump can't be limited to self entries, on a host with bridges "ip maddr show" would receive the whole learned FDB of every port and drop it. It would still need a new uAPI. All self entries are NUD_PERMANENT, so the users count and the SIOCADDMULTI (static) bit would be new NDA_* attributes. On the other hand, this series adds no new attributes; IFA_MULTICAST, IFA_MC_USERS and IFA_F_PERMANENT already exist for the IPv4 and IPv6 dumps. Covering this with RTM_GETNEIGH would need the default dump for devices with their own ndo_fdb_dump, a way to tell filter entries from a device's own NTF_SELF FDB entries, a self-only request filter, and new NDA_* attributes for users and the static bit. That is more new uAPI than this series for the same result. Therefore, I feel that my original proposal seems cleaner and causes less chrun. But feel free to let me know if I have any misunderstanding on the suggestion. > FWIW, AF_PACKET seems strange to me. Isn't AF_UNSPEC (like for interface, cf > rtnl_fill_ifinfo) more appropriate? For address dumps AF_UNSPEC already means "all families" (RTM_GETADDR goes through rtnl_dump_all()), so I'd rather keep it available for RTM_GETMULTICAST. AF_PACKET is what iproute2 already uses for the link family: "ip -0" sets preferred_family = AF_PACKET and sends it in RTM_GETLINK, and ipmaddr.c has always tagged the /proc/net/dev_mcast entries as AF_PACKET. Thanks, Yuyang
