netdev - Re: [RFC] change the default Kconfig value of mlx5

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]

Date:   Sat, 22 Apr 2017 03:34:06 +0300
From:   Saeed Mahameed <saeedm@....mellanox.co.il>
To:     Ian Kumlien <ian.kumlien@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [RFC] change the default Kconfig value of mlx5_en

On Sat, Apr 22, 2017 at 2:10 AM, Ian Kumlien <ian.kumlien@...il.com> wrote:
> Sorry,
>
> Back again, fighting cold, hot whiskey has been consumed...
>
> Something like this would perhaps be a better solution:
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> index 60154a175bd3..fe192e247601 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -1139,6 +1139,10 @@ static int mlx5_load_one(struct mlx5_core_dev
> *dev, struct mlx5_priv *priv,
>
>  #ifdef CONFIG_MLX5_CORE_EN
>         mlx5_eswitch_attach(dev->priv.eswitch);
> +#else
> +       if (MLX5_CAP_GEN(dev, port_type) == MLX5_CAP_PORT_TYPE_ETH) {
> +               dev_info(&pdev->dev, "Ethernet device discovered but
> support not enabled in kernel.");
> +       }
>  #endif
>

Currently both MLX5_CORE=n and MLX5_CORE_EN=n as a default, the issue
you are seeing can occur only if you explicitly  set MLX5_CORE=y and
MLX5_CORE=n, Why would someone do this if he knows he wants Ethernet
support as well ? IMHO this print is redundant .

Anyway, Are you looking for RDMA support over ethernet (RoCE) ? and
you are not interested to have ethernet netdev support ?

if yes, I think this is something that can be achieved, but the
question is do we really need this ?