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
