Hi,

I'm sorry for the long delay, I was (and still I am) diverted by some
other duty.

On Fri, 2018-12-07 at 21:46 +0000, David Woodhouse wrote:

On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote:

quoted

quoted

I wonder if we can declare the common case functions as 'weak' so that
the link failures don't happen when they're absent.

I experimented a previous version with alias. I avoided weak alias
usage, because I [mis?]understood not all compilers have a complete
support for them (e.g. clang).
Also, with weak ref, a coding error that is now discovered at build
time will result in worse performance at runtime, likely with some
uncommon configuration, possibly not as easily detected. I'm unsure
that would be better ?!?

I think everything supports weak linkage; we've been using it for
years.

Ok, I likely was confused by some old, non first-hand info.

Anyway weak alias will turn a compile time issue in a possible run-time 
(small) regression. I think the first option would be preferable.

quoted

I'm sorry, I don't follow here. I think static keys can't be used for
the reported network case: we have different list elements each
contaning a different function pointer and we access/use
different ptr on a per packet basis.

Yes, the alternatives would be used to change the "likely" case.

We still do the "if (fn == default_fn) default_fn(); else (*fn)();"
part; or even the variant with two (or more) common cases. 

It's just that the value of 'default_fn' can be changed at runtime
(with patching like alternatives/static keys, since of course it has to
be a direct call).

Thanks for clarifying. If I understood correctly, you would like some
helper for:

if (static_branch_likely(&use_default_fn_a))
    INDIRECT_CALL_1(f, default_fn_a, <args>)
else if (static_branch_likely(&use_default_fn_b))
    INDIRECT_CALL_1(f, default_fn_b, <args>)
// ...

if so, I think we can eventually add support for this kind of stuff on
top of the proposed macros. WDYT?

Thanks,

Paolo