On Wed, 30 Mar 2022 19:16:42 +0300 Nikolay Aleksandrov wrote: > > Maybe opt-out? But assuming the event is only generated on > > active/backup switch over - when would it be okay to ignore > > the notification? > > Let me just clarify, so I'm sure I've not misunderstood you. Do you mean opt-out as in > make it default on? IMO that would be a problem, large scale setups would suddenly > start propagating it to upper devices which would cause a lot of unnecessary bcast. > I meant enable it only if needed, and only on specific ports (second part is not > necessary, could be global, I think it's ok either way). I don't think any setup > which has many upper vlans/macvlans would ever enable this. That may be. I don't have a good understanding of scenarios in which GARP is required and where it's not :) Goes without saying but the default should follow the more common scenario. > >> My concern was about the Hangbin's alternative proposal to notify all > >> bridge ports. I hope in my porposal I was able to avoid infinite loops. > > > > Possibly I'm confused as to where the notification for bridge master > > gets sent.. > > IIUC it bypasses the bridge and sends a notify peers for the veth peer so it would > generate a grat arp (inetdev_event -> NETDEV_NOTIFY_PEERS). Ack, I was basically repeating the question of where does the notification with dev == br get generated. There is a protection in this patch to make sure the other end of the veth is not plugged into a bridge (i.e. is not a bridge port) but there can be a macvlan on top of that veth that is part of a bridge, so IIUC that check is either insufficient or unnecessary.
