[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c27cdb3-bb8f-02b7-477e-e82d113b2b6d@mellanox.com>
Date: Fri, 13 Jul 2018 16:03:01 -0400
From: Boris Pismenny <borisp@...lanox.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, davejwatson@...com, aviadye@...lanox.com,
saeedm@...lanox.com
Subject: Re: [PATCH v4 net-next 19/19] net/mlx5e: Kconfig, mutually exclude
compilation of TLS and IPsec accel
On 7/12/2018 8:44 PM, David Miller wrote:
> From: Boris Pismenny <borisp@...lanox.com>
> Date: Thu, 12 Jul 2018 22:25:57 +0300
>
>> We currently have no devices that support both TLS and IPsec using the
>> accel framework, and the current code does not support both IPsec and
>> TLS. This patch prevents such combinations.
>>
>> Signed-off-by: Boris Pismenny <borisp@...lanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
>> index 2545296..d3e8c70 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
>> @@ -93,6 +93,7 @@ config MLX5_EN_TLS
>> depends on TLS_DEVICE
>> depends on TLS=y || MLX5_CORE=m
>> depends on MLX5_ACCEL
>> + depends on !MLX5_EN_IPSEC
>> default n
>
> You absolutely cannot do this.
>
> You are forcing a distribution to pick one offload or the other at
> build time, that's insane.
>
> Please find a way to support both offloads in the driver. It is
> absolutely valid for a distribution to ship the driver in a state that
> supports both offloads and you must therefore support this properly.
>
> Thank you.
>
Thanks Dave.
We currently have no devices that support both TLS and IPsec using the
accel framework, and the current code does not support both IPsec and
TLS. The purpose of this patch was to prevent such cases using Kconfig.
Looking a bit more carefully at the code. We don't need this patch,
because we still don't have a deviceID for both TLS and IPsec, so the
problematic flow cannot happen. So we've just been over zealous here.
I'll remove this patch and send a v5.
Powered by blists - more mailing lists