[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <113bea13-8f7e-af0c-50de-936112a1bc48@gmail.com>
Date: Wed, 13 Jan 2021 19:07:20 +0200
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Alexander Duyck <alexander.duyck@...il.com>,
rohit maheshwari <rohitm@...lsio.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>, secdev@...lsio.com,
Alexei Starovoitov <ast@...nel.org>,
Björn Töpel <bjorn.topel@...el.com>,
Daniel Borkmann <daniel@...earbox.net>, andriin@...com,
Eric Dumazet <edumazet@...gle.com>,
Cong Wang <xiyou.wangcong@...il.com>, ap420073@...il.com,
Jiri Pirko <jiri@...lanox.com>, borisp@...dia.com,
Tariq Toukan <ttoukan.linux@...il.com>,
Tariq Toukan <tariqt@...dia.com>
Subject: Re: [net] net: feature check mandating HW_CSUM is wrong
On 1/13/2021 5:35 AM, Alexander Duyck wrote:
> On Tue, Jan 12, 2021 at 6:43 PM rohit maheshwari <rohitm@...lsio.com> wrote:
>>
>>
>> On 07/01/21 12:47 AM, Jakub Kicinski wrote:
>>> On Wed, 6 Jan 2021 23:23:27 +0530 Rohit Maheshwari wrote:
>>>> Mandating NETIF_F_HW_CSUM to enable TLS offload feature is wrong.
>>>> And it broke tls offload feature for the drivers, which are still
>>>> using NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM. We should use
>>>> NETIF_F_CSUM_MASK instead.
>>>>
>>>> Fixes: ae0b04b238e2 ("net: Disable NETIF_F_HW_TLS_TX when HW_CSUM is disabled")
>>>> Signed-off-by: Rohit Maheshwari <rohitm@...lsio.com>
>>> Please use Tariq's suggestion.
>> HW_TLS_TX feature is for both IPv4/v6. And If one device is limited to
>> support only IPv4 checksum offload, TLS offload should be allowed for
>> that too. So I think putting a check of CSUM_MASK is enough.
>
> The issue is that there is no good software fallback if the packet
> arrives at the NIC and it cannot handle the IPv6 TLS offload.
>
> The problem with the earlier patch you had is that it was just
> dropping frames if you couldn't handle the offload and "hoping" the
> other end would catch it. That isn't a good practice for any offload.
> If you have it enabled you have to have a software fallback and in
> this case it sounds like you don't have that.
>
> In order to do that you would have to alter the fast path to have to
> check if the device is capable per packet which is really an
> undesirable setup as it would add considerable overhead and is open to
> race conditions.
>
+1
Are there really such modern devices with missing IPv6 csum
capabilities, or it's just a missing SW implementation in the device driver?
IMO, it sounds reasonable for this modern TLS device offload to asks for
a basic requirement such as IPv6 csum offload capability, to save the
overhead.
Powered by blists - more mailing lists