netdev - Re: [PATCH v27 15/20] net/mlx5e: NVMEoTCP, use KLM UMRs for buffer registration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e747a278-7cc9-433f-b093-56487c629d3a@grimberg.me>
Date: Mon, 14 Apr 2025 00:34:17 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Aurelien Aptel <aaptel@...dia.com>, Christoph Hellwig <hch@....de>
Cc: Simon Horman <horms@...nel.org>, kuba@...nel.org,
 linux-nvme@...ts.infradead.org, netdev@...r.kernel.org, kbusch@...nel.org,
 axboe@...com, chaitanyak@...dia.com, davem@...emloft.net,
 aurelien.aptel@...il.com, smalin@...dia.com, malin1024@...il.com,
 ogerlitz@...dia.com, yorayz@...dia.com, borisp@...dia.com,
 galshalom@...dia.com, mgurtovoy@...dia.com, tariqt@...dia.com
Subject: Re: [PATCH v27 15/20] net/mlx5e: NVMEoTCP, use KLM UMRs for buffer
 registration

On 11/04/2025 16:24, Aurelien Aptel wrote:
> Christoph Hellwig <hch@....de> writes:
>> Btw, just as a reminder nvme code has to go through the nvme tree, and
>> there is absolutely no consesnsus on this feature yet.
> Sagi, could you give your input on this?

As mentioned before, my personal opinion is in favor of getting this 
upstream. 6 years into nvme-tcp,
some people (which are allergic to rdma) are asking for less CPU 
utilization. This would be an optional
compromise to these users. I've expressed concerns that this offload has 
been poorly designed because
it does not interoperate with TLS (offload nor SW). This is somewhat of 
a turn off. I will say that having this
work with TLS offload would make it a more appealing feature than what 
it is right now.

I think that the hesitance is understandable given the history of 
storage offload engines which never really
justified their own existence.

As mentioned before, I acked the series, as I think that this could 
benefit users, despite adding foreign single-vendor
offload code to the driver (granted, not a niche vendor).