netdev - Re: [PATCH net-next] net/smc: increase SMC_WR_BUF

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: <7569a727-ad3e-4dfa-8c9e-e135c61e1493@redhat.com>
Date: Tue, 5 Nov 2024 11:16:00 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Halil Pasic <pasic@...ux.ibm.com>, Dust Li <dust.li@...ux.alibaba.com>
Cc: Wenjia Zhang <wenjia@...ux.ibm.com>, Wen Gu <guwen@...ux.alibaba.com>,
 "D. Wythe" <alibuda@...ux.alibaba.com>, Tony Lu <tonylu@...ux.alibaba.com>,
 David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
 linux-s390@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
 Jan Karcher <jaka@...ux.ibm.com>, Gerd Bayer <gbayer@...ux.ibm.com>,
 Alexandra Winter <wintera@...ux.ibm.com>, Nils Hoppmann
 <niho@...ux.ibm.com>, Niklas Schnell <schnelle@...ux.ibm.com>,
 Thorsten Winkler <twinkler@...ux.ibm.com>,
 Karsten Graul <kgraul@...ux.ibm.com>, Stefan Raspl <raspl@...ux.ibm.com>
Subject: Re: [PATCH net-next] net/smc: increase SMC_WR_BUF_CNT

On 11/4/24 17:42, Halil Pasic wrote:
> On Thu, 31 Oct 2024 13:30:17 +0100
> Halil Pasic <pasic@...ux.ibm.com> wrote:
> 
>> On Sat, 26 Oct 2024 07:58:39 +0800
>> Dust Li <dust.li@...ux.alibaba.com> wrote:
>>
>>>> For some reason include/linux/wait.h does not offer a top level wrapper
>>>> macro for wait_event with interruptible, exclusive and timeout. I did
>>>> not spend too many cycles on thinking if that is even a combination that
>>>> makes sense (on the quick I don't see why not) and conversely I
>>>> refrained from making an attempt to accomplish the interruptible,
>>>> exclusive and timeout combo by using the abstraction-wise lower
>>>> level __wait_event interface.
>>>>
>>>> To alleviate the tx performance bottleneck and the CPU overhead due to
>>>> the spinlock contention, let us increase SMC_WR_BUF_CNT to 256.    
>>>
>>> Hi,
>>>
>>> Have you tested other values, such as 64? In our internal version, we
>>> have used 64 for some time.  
>>
>> Yes we have, but I'm not sure the data is still to be found. Let me do
>> some digging.
>>
> 
> We did some digging and according to that data 64 is not likely to cut
> it on the TX end for highly parallel request-response workload. But we
> will measure some more these days just to be on the safe side.
> 
>>>
>>> Increasing this to 256 will require a 36K continuous physical memory
>>> allocation in smc_wr_alloc_link_mem(). Based on my experience, this may
>>> fail on servers that have been running for a long time and have
>>> fragmented memory.  
>>
>> Good point! It is possible that I did not give sufficient thought to
>> this aspect.
>>
> 
> The failing allocation would lead to a fallback to TCP I believe. Which
> I don't consider a catastrophic failure.
> 
> But let us put this patch on hold and see if we can come up with
> something better.

FTR, I marked this patch as 'changes requested' given the possible risk
of regressions (more frequent fallback to TCP).

We can revive it should an agreement be reached.

Thanks,

Paolo