[lkml]   [2018]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH net-next v2 1/4] indirect call wrappers: helpers to speed-up indirect calls of builtin
On Wed, 2018-12-05 at 19:13 +0100, Paolo Abeni wrote:
> +/*
> + * We can use INDIRECT_CALL_$NR for ipv6 related functions only if ipv6 is
> + * builtin, this macro simplify dealing with indirect calls with only ipv4/ipv6
> + * alternatives
> + */
> +#define INDIRECT_CALL_INET(f, f2, f1, ...) \
> + INDIRECT_CALL_2(f, f2, f1, __VA_ARGS__)
> +#define INDIRECT_CALL_INET(f, f2, f1, ...) INDIRECT_CALL_1(f, f1, __VA_ARGS__)
> +#else
> +#define INDIRECT_CALL_INET(f, f2, f1, ...) f(__VA_ARGS__)
> +#endif
> +
> +#endif

Thanks for working on this.

I'm not stunningly keen on the part cited above. And it doesn't seem to
be working either, given Dave's later error and reversion.

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

Once we extend this past the network code, especially to file systems'
f_ops, I suspect we're going to want to use something like static keys
to patch the common cases at runtime — perhaps changing the f_ops
default according to what the root file system is, etc.

I'd quite like to see the API for this taking that into account even if
it's left to be a future development.

[unhandled content-type:application/x-pkcs7-signature]
 \ /
  Last update: 2018-12-07 10:46    [W:0.108 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site