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

[Sagi Grimberg]

On 11/04/2025 16:24, Aurelien Aptel wrote:
> Christoph Hellwig <hch at lst.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).