On 16 Nov 2023, at 12:10, David Marchand wrote:
> Hello Eelco, > > On Thu, Nov 16, 2023 at 11:57 AM Eelco Chaudron <echau...@redhat.com> wrote: > > [snip] > >>> +bridge("br0") >>> +------------- >>> + 0. priority 32768 >>> + NORMAL >>> + -> forwarding to mcast group port >>> + -> forwarding to mcast flood port >>> + >>> +Final flow: unchanged >>> +Megaflow: >>> recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_dst=224.1.1.1,nw_frag=no >>> +Datapath actions: 1,2 >> >> >> Are we sure the order here is always 1,2 vs the first test you sorted them? >> Same for all the other multi-port tests below? >> >> I did run the test 200+ times, and it seems ok. Trying to understand this, >> as I can see the first one reporting 100,1,2 and 100,2,1. > > struct mcast_output out = MCAST_OUTPUT_INIT; > ... > if (grp) { > xlate_normal_mcast_send_group(ctx, ms, grp, in_xbundle, &out); > xlate_normal_mcast_send_fports(ctx, ms, in_xbundle, &out); > xlate_normal_mcast_send_mrouters(ctx, ms, in_xbundle, &xvlan, > &out); > ... > mcast_output_finish(ctx, &out, in_xbundle, &xvlan); > > With: > static void > mcast_output_finish(struct xlate_ctx *ctx, struct mcast_output *out, > struct xbundle *in_xbundle, struct xvlan *xvlan) > { > if (out->flood) { > xlate_normal_flood(ctx, in_xbundle, xvlan); > } else { > for (size_t i = 0; i < out->n; i++) { > output_normal(ctx, out->xbundles[i], xvlan); > } > } > ... > > > In this case, there is no flooding (contrary to previous tests) over > all the ports from this bridge. > There is only one "group" port and one "flood" port and the order is fixed. Thanks, now it makes sense :) //Eelco _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev