net/mlx5: enhance error log for tunnel offloading

  Tunnel offloading is linked to running a port with the non-obvious
dv_xmeta_en=3 devargs. Hint at it for "normal" users.

Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 drivers/net/mlx5/mlx5_flow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Hello guys,

On Thu, Apr 27, 2023 at 1:56 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Tunnel offloading is linked to running a port with the non-obvious
> dv_xmeta_en=3 devargs. Hint at it for "normal" users.
>
> Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>

Regardless of what happens to this patch, would it be possible to move
away from those dv_xxx_en devargs things and go with a more
straightforward API, like requesting tunnel offloading (or other) in
rte_flow_configure?
  

Hello David,

> Tunnel offloading is linked to running a port with the non-obvious
> dv_xmeta_en=3 devargs. Hint at it for "normal" users.
> 
> Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
>  drivers/net/mlx5/mlx5_flow.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index d0275fdd00..51f6ecd25d 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -11295,7 +11295,7 @@ mlx5_flow_tunnel_validate(struct rte_eth_dev
> *dev,
>         if (!is_tunnel_offload_active(dev))
>                 return rte_flow_error_set(error, ENOTSUP,
>                                           RTE_FLOW_ERROR_TYPE_ACTION_CONF, NULL,
> -                                         "tunnel offload was not activated");
> +                                         "tunnel offload was not activated, consider
> setting dv_xmeta_en=3");
>         if (!tunnel)
>                 return rte_flow_error_set(error, EINVAL,
>                                           RTE_FLOW_ERROR_TYPE_ACTION_CONF, NULL,
> --
> 2.40.0

Reviewed-by: Gregory Etelson <getelson@nvidia.com>
  

Hi,

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Thursday, April 27, 2023 2:56 PM
> To: dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Gregory Etelson <getelson@nvidia.com>
> Subject: [PATCH] net/mlx5: enhance error log for tunnel offloading
> 
> Tunnel offloading is linked to running a port with the non-obvious
> dv_xmeta_en=3 devargs. Hint at it for "normal" users.
> 
> Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Raslan Darawsheh <rasland@nvidia.com>

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh
  

27/04/2023 14:23, David Marchand:
> Hello guys,
> 
> On Thu, Apr 27, 2023 at 1:56 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > Tunnel offloading is linked to running a port with the non-obvious
> > dv_xmeta_en=3 devargs. Hint at it for "normal" users.
> >
> > Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> 
> Regardless of what happens to this patch, would it be possible to move
> away from those dv_xxx_en devargs things and go with a more
> straightforward API, like requesting tunnel offloading (or other) in
> rte_flow_configure?

Yes it is a good idea to use rte_flow_configure() for such configuration
of the ethernet port.
If we get application requirements dynamically,
then we can better allocate resources
and check for invalid combinations of features.