Attention is currently required from: daniel, fixeria, laforge, osmith.

pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/42105?usp=email )

Change subject: Introduce struct osmo_ss7_as_asp_assoc ......................................................................

Patch Set 1:

(1 comment)

Patchset:

PS1:

Sadly I'm not super excited about having a linear list iteration everywehre where so far we simply h […]

We are usually talking about a handful of ASPs here, up to 16 if comparing to previous setups, so it's not like we are talking about iterating super long lists.

Talking about userplane traffic forwarding, we focus on selecting an ASP given an AS, depending on traffic mode: * loadshare: not really affected in hot path, only when deciding to select/change a given normal/alternative destination in the binding table due to it changing status. * roundrobin: ss7_as_select_asp_roundrobin() In general it will simply pick the next in the list, number of jumps depend on how many active we have. As mentioned this can be optimized later by having an extra "asp_active_list". * override: ss7_as_select_asp_override(), this may be the only one which may want to traverse most of the llist in certain conditions. As mentioned this can be optimized later by having an extra "asp_active_list", or by moving an ASP fist in the llist when it is activated. * broadcast: Not sure somebody really wants to use broadcast with a big amount of ASPs anyway...

Moreover, most of those loops are not really tight loops, since they are calling functions for each asp, etc.

BTW, fyi, we are already using llists in the previous step when selecting an AS from the combined linkset, which always happens in loadshare mode. This is a first implementation to at least support more ASPs. We can always later on optimize the bottlenecks adding separate llists for eg. active ASPs, adding hashtables to look up for ASP in an AS, etc.

In any case, it doesn't make sense imho to try to accomplish all of that in the same first commit, the changes are big/complex enough as of current change. I still plan to submit more follow-up patches wrt this topic.