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

Reply via email to