On Thu, Jul 11, 2019 at 05:20:58PM +0200, Dumitru Ceara wrote: > While doing some scale testing I realized that walking the rows of the > IGMP_Group table in ovn-northd in the order we get them from the > database might create an issue: ovn_igmp_group_add will create a new > multicast_group for every unique IGMP group address and allocate a > tunnel-id for it. However, because rows are not processed in the order > they were added to the database, it can happen that multicast groups > that didn't actually change will get a different tunnel-id triggering > a change in the associated logical flows.
Ouch. Let's avoid that problem! > 2. Maintain a cache (hashtable) of allocated multicast group > tunnel-ids between subsequent runs of the ovn-northd loop: > - Once all IGMP_Group entries are processed and their corresponding > Multicast_Group entries are collected we'd need to store a mapping > (per datapath) between IGMP group address and multicast group > tunnel-id. > - Next time ovn-northd walks the IGMP_Group table, before allocating a > new tunnel-id for a multicast group entry it would check the "cache" > from the previous run. If there's already an entry it would reuse the > tunnel-id. If not, it will have to allocate a tunnel-id. Store the > (IGMP group address, tunnel-id) mapping for next run. This is the customary way, so it's what I recommend. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
