netdev - Re: [PATCH v7 18/28] sfc: get endpoint decoder

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2e6e24ed-d0aa-f4a1-5215-32053c7b45d0@amd.com>
Date: Wed, 11 Dec 2024 09:15:37 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: Edward Cree <ecree.xilinx@...il.com>, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, dan.j.williams@...el.com,
 martin.habets@...inx.com, edward.cree@....com, davem@...emloft.net,
 kuba@...nel.org, pabeni@...hat.com, edumazet@...gle.com, dave.jiang@...el.com
Subject: Re: [PATCH v7 18/28] sfc: get endpoint decoder

On 12/11/24 00:25, Edward Cree wrote:
> On 09/12/2024 18:54, alejandro.lucero-palau@....com wrote:
>> From: Alejandro Lucero <alucerop@....com>
>>
>> Use cxl api for getting DPA (Device Physical Address) to use through an
>> endpoint decoder.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@....com>
>> Reviewed-by: Martin Habets <habetsm.xilinx@...il.com>
> Acked-by: Edward Cree <ecree.xilinx@...il.com>

Thanks

>> +	cxl->cxled = cxl_request_dpa(cxl->cxlmd, true, EFX_CTPIO_BUFFER_SIZE,
>> +				     EFX_CTPIO_BUFFER_SIZE);
> Just for my education, could you explain what's the difference between
>   cxl_dpa_alloc(..., size) and cxl_request_dpa(..., size, size)?  Since
>   you're not really making use of the min/max flexibility here, I assume
>   there's some other reason for using the latter.  Is it just that it's
>   a convenience wrapper that saves open-coding some of the boilerplate?

A device advertises CXL memory but the Host being able to map it depends 
on the current state of CXL configuration regarding CXL decoders in the 
path to the device and the request itself.

Our case is simple since we rely on having all that memory mapped or not 
having it at all. And we count on our device being directly connected to 
the CXL Root Complex or to one of the CXL Root Complex available, but 
CXL switches and things like memory interleaving can make things far 
more complex.

About min and max, the former specifies the minimal driver requirements 
for mapping CXL memory, and the latter tells about the maximal size the 
driver could be interested in. I think this is more a legacy of how 
Type3 devices are managed and arguably not so important for 
accelerators, and for some as ours, not needed.