On Fri, Jul 12, 2019 at 7:34 PM Ben Pfaff <[email protected]> wrote: > > 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.
I'm working on it and I'll send out a v4 soon. Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
