Round Robin Hashes behaving on an action profile vs group basis

[matthewtlam]

Upon doing tests with round robin, it seems that the behavior turns the round robin wheels on an "individual" basis, but it's on a per action profile basis rather than on a group basis.

The following example has the members of the two groups of the same type being non co-prime (i.e. two ars_groups with non co-prime number of members). Here we get round robin behaving on a per action profile basis: (group_1, 1), (group_2, 3), (group_1, 2), (group_2, 4), (group_1, 1), (group_2, 5), (group_1_ 2), (group_2, 6). This works as expected.

                    overlay_group
                    /           \
            ars_group_1        ars_group_2
             /   |            /   |    |   \
Ports:      1    2           3    4    5    6 

Another example here where the members of the group are co-prime, but uses two different groups. Here, we get round robin based on the individual groups, which also produces the result as expected.

                    overlay_group
                    /           \
            ars_group_1       wcmp_group_1
             /     \         /      |      \
Ports:      1       2       3       4       5

However, in this case where we have non co-prime sized members of two of the same group (2 ars groups), then we get the following behavior: (group_1, 1), (group_2, 4), (group_1, 1), (group_2, 3), (group_1, 1), (group_2, 5). Note that we skip the member (group_1, 2) entirely).

                    overlay_group
                    /           \
             ars_group_1       ars_group_2
               /     \        /     |     \
Ports:        1      2        3     4     5

@antoninbas do you know how much effort and potential performance cost of having the round robin hashes (potentially all hashes) live on a per-group basis, rather than a per-action profile basis?

cc: @jonathan-dilorenzo, @smolkaj

[jafingerhut]

I do not know this code base nearly as well as Antonin does, but I am pretty confident that packet processing performance would not change in any easily-measurable way with such a change, as long as it was implemented in a not-obviously-poor-performance way, e.g. maintaining a last round-robin member used per group/whatever-is-needed-for-correct-behavior, and reading it and updating it whenever a packet uses the group.

The effort required depends on how quickly you and/or your favorite AI assistant can understand the existing code and figure out what needs to be changed. For me, without an AI assistant, I'd guesstimate a week of finding the relevant parts of code, adding debug print statements to verify it works as I expect currently, and updating it after being confident I'm in the right area of the code that needs changing, debugging,and preferably adding a unit test case or three.