[net-next,v3,0/2] net/mlx5: use indirect call wrappers

The mlx5_core driver uses several indirect calls in fast-path, some of them
are invoked on each ingress packet, even for the XDP-only traffic.

This series leverage the indirect call wrappers infrastructure the avoid
the expansive RETPOLINE overhead for 2 indirect calls in fast-path.

Each call is addressed on a different patch, plus we need to introduce a couple
of additional helpers to cope with the higher number of possible direct-call
alternatives.

v2 -> v3:
 - do not add more INDIRECT_CALL_* macros
 - use only the direct calls always available regardless of
   the mlx5 build options in the last patch

v1 -> v2:
 - update the direct call list and use a macro to define it,
   as per Saeed suggestion. An intermediated additional
   macro is needed to allow arg list expansion
 - patch 2/3 is unchanged, as the generated code looks better this way than
   with possible alternative (dropping BP hits)

Paolo Abeni (2):
  net/mlx5e: use indirect calls wrapper for skb allocation
  net/mlx5e: use indirect calls wrapper for the rx packet handler

 .../net/ethernet/mellanox/mlx5/core/en_rx.c   | 25 ++++++++++++++-----
 1 file changed, 19 insertions(+), 6 deletions(-)

From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 12 Jun 2019 12:18:34 +0200

> The mlx5_core driver uses several indirect calls in fast-path, some of them
> are invoked on each ingress packet, even for the XDP-only traffic.
> 
> This series leverage the indirect call wrappers infrastructure the avoid
> the expansive RETPOLINE overhead for 2 indirect calls in fast-path.
> 
> Each call is addressed on a different patch, plus we need to introduce a couple
> of additional helpers to cope with the higher number of possible direct-call
> alternatives.
> 
> v2 -> v3:
>  - do not add more INDIRECT_CALL_* macros
>  - use only the direct calls always available regardless of
>    the mlx5 build options in the last patch
> 
> v1 -> v2:
>  - update the direct call list and use a macro to define it,
>    as per Saeed suggestion. An intermediated additional
>    macro is needed to allow arg list expansion
>  - patch 2/3 is unchanged, as the generated code looks better this way than
>    with possible alternative (dropping BP hits)

Applied, thanks.