netdev - Re: [PATCH net-next 2/3] indirect call wrappers: add helpers for 3 and 4 ways switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1133f7e92cffb7ade5249e6d6ac0dd430549bf14.camel@mellanox.com>
Date:   Fri, 31 May 2019 18:30:41 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "leon@...nel.org" <leon@...nel.org>
Subject: Re: [PATCH net-next 2/3] indirect call wrappers: add helpers for 3
 and 4 ways switch

On Fri, 2019-05-31 at 14:53 +0200, Paolo Abeni wrote:
> Experimental results[1] has shown that resorting to several branches
> and a direct-call is faster than indirect call via retpoline, even
> when the number of added branches go up 5.
> 
> This change adds two additional helpers, to cope with indirect calls
> with up to 4 available direct call option. We will use them
> in the next patch.
> 
> [1] 
> https://linuxplumbersconf.org/event/2/contributions/99/attachments/98/117/lpc18_paper_af_xdp_perf-v2.pdf
> 
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
> ---
>  include/linux/indirect_call_wrapper.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/linux/indirect_call_wrapper.h
> b/include/linux/indirect_call_wrapper.h
> index 00d7e8e919c6..7c4cac87eaf7 100644
> --- a/include/linux/indirect_call_wrapper.h
> +++ b/include/linux/indirect_call_wrapper.h
> @@ -23,6 +23,16 @@
>  		likely(f == f2) ? f2(__VA_ARGS__) :			
> \
>  				  INDIRECT_CALL_1(f, f1, __VA_ARGS__);	
> \
>  	})
> +#define INDIRECT_CALL_3(f, f3, f2, f1, ...)				
> \
> +	({								
> \
> +		likely(f == f3) ? f3(__VA_ARGS__) :			
> \
> +				  INDIRECT_CALL_2(f, f2, f1,
> __VA_ARGS__); \
> +	})
> +#define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...)			
> 	\
> +	({								
> \
> +		likely(f == f4) ? f4(__VA_ARGS__) :		

do we really want "likely" here ? in our cases there is no preference
on whuch fN is going to have the top priority, all of them are equally
important and statically configured and guranteed to not change on data
path .. 

> 	\
> +				  INDIRECT_CALL_3(f, f3, f2, f1,
> __VA_ARGS__); \
> +	})
>  

Oh the RETPOLINE!

On which (N) where INDIRECT_CALL_N(f, fN, fN-1, ..., f1,...) , calling
the indirection function pointer directly is going to be actually
better than this whole INDIRECT_CALL_N wrapper "if else" dance ?

>  #define INDIRECT_CALLABLE_DECLARE(f)	f
>  #define INDIRECT_CALLABLE_SCOPE
> @@ -30,6 +40,8 @@
>  #else
>  #define INDIRECT_CALL_1(f, f1, ...) f(__VA_ARGS__)
>  #define INDIRECT_CALL_2(f, f2, f1, ...) f(__VA_ARGS__)
> +#define INDIRECT_CALL_3(f, f3, f2, f1, ...) f(__VA_ARGS__)
> +#define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...) f(__VA_ARGS__)
>  #define INDIRECT_CALLABLE_DECLARE(f)
>  #define INDIRECT_CALLABLE_SCOPE		static
>  #endif