[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0ea3e0c4-b16e-148b-8dea-7e1fc3dec465@gmail.com>
Date: Wed, 6 Jan 2021 09:39:57 +0200
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>,
Rohit Maheshwari <rohitm@...lsio.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, secdev@...lsio.com,
Tariq Toukan <tariqt@...dia.com>,
Boris Pismenny <borisp@...dia.com>
Subject: Re: [net] cxgb4: advertise NETIF_F_HW_CSUM
On 1/5/2021 10:29 PM, Jakub Kicinski wrote:
> On Tue, 5 Jan 2021 22:27:49 +0530 Rohit Maheshwari wrote:
>> advertise NETIF_F_HW_CSUM instead of protocol specific values of
>> NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. This change is added long
>> back in other drivers. This issue is seen recently when TLS offload
>> made it mandatory to enable NETIF_F_HW_CSUM.
>>
>> Fixes: 2ed28baa7076 ("net: cxgb4{,vf}: convert to hw_features")
>> Signed-off-by: Rohit Maheshwari <rohitm@...lsio.com>
>
> Ugh, commit ae0b04b238e2 ("net: Disable NETIF_F_HW_TLS_TX when HW_CSUM
> is disabled") is buggy, it should probably use NETIF_F_CSUM_MASK.
> Can you fix that instead?
>
The HW_TLS_TX feature is for both IPv4/6. We do not want to allow
NETIF_F_HW_TLS_TX if only one of (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM)
is set (of course NETIF_F_HW_CSUM is not set in this case).
Hence, using NETIF_F_CSUM_MASK would not be a strong enough condition.
I think we have two options here:
Either (1) request device drivers to move to NETIF_F_HW_CSUM if they
want to have HW_TLS_TX (as it is today), or (2) use the following condition:
((features & NETIF_F_IP_CSUM) && (features & NETIF_F_IPV6_CSUM)) ||
(features & NETIF_F_HW_CSUM).
Thanks,
Tariq
Powered by blists - more mailing lists