All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Moritz Wanzenböck" <moritz.wanzenboeck@linbit.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: kernel-tls-handshake <kernel-tls-handshake@lists.linux.dev>,
	Paolo Abeni <pabeni@redhat.com>
Subject: Re: low pending handshake limit
Date: Tue, 05 Sep 2023 10:56:14 +0200	[thread overview]
Message-ID: <QT8I0S.51IG54TEPYUC3@linbit.com> (raw)
In-Reply-To: <90B2279F-F69B-43D2-B809-006519825D62@oracle.com>

Hi Chuck,

On Mo, Sep 4 2023 at 15:13:25 +0000, Chuck Lever III 
<chuck.lever@oracle.com> wrote:
> Hi-
> 
>>  On Sep 4, 2023, at 8:39 AM, Moritz Wanzenböck 
>> <moritz.wanzenboeck@linbit.com> wrote:
>> 
>>  Hi all,
>> 
>>  I'm currently working on enabling TLS support for DRBD, so I'm very 
>> keen to use the handshake infrastructure.
> 
> I'm happy to see the handshake infrastructure get more usage.
> 
> 
>>  During testing I noticed that the allowed number of pending 
>> handshakes is quite low. This seems to stem from the following 
>> calculation:
>> 
>>  /*
>>  * Arbitrary limit to prevent handshakes that do not make
>>  * progress from clogging up the system. The cap scales up
>>  * with the amount of physical memory on the system.
>>  */
>>  si_meminfo(&si);
>>  tmp = si.totalram / (25 * si.mem_unit);
>>  hn->hn_pending_max = clamp(tmp, 3UL, 50UL);
>> 
>>  Which, for the typical VMs I use for testing (1Gi RAM), ends up 
>> being just 3 handshakes. The limits in general seem too low also in 
>> the best case. If a node just booted, and would start connecting to 
>> all configured DRBD devices, we could easily hit even the upper 
>> limit of 50.
>> 
>>  Also the calculation used doesn't seem to make too much sense to 
>> me. It allows more handshakes when using a smaller page size?
>> 
>>  Would it be possible to increase the number of pending handshakes?
> 
> IIRC I added the dynamic computation in response to a review
> comment from Paolo (cc'd). I think the limit values are arbitrary,
> we just want a sensible cap on the number of pending handshakes,
> and on smaller systems, that limit should be a smaller value.
> 
> It's true that a handshake can fail if that limit is hit, but
> the consumer ought to be able to retry after a brief delay in
> that case.
> 
> I am open to discussing changes if retrying proves to be a
> challenge.

Thanks for the explanation. Actually, retrying is not an issue. I was 
initially
vary, I thought the requests remained pending until the handshake was 
complete.
Looks like I was wrong about that, it's just pending until the netlink 
message
is sent to the user space utility.

Best regards,
Moritz



  reply	other threads:[~2023-09-05  8:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04 12:39 low pending handshake limit Moritz Wanzenböck
2023-09-04 15:13 ` Chuck Lever III
2023-09-05  8:56   ` Moritz Wanzenböck [this message]
2023-09-05 11:30     ` Paolo Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=QT8I0S.51IG54TEPYUC3@linbit.com \
    --to=moritz.wanzenboeck@linbit.com \
    --cc=chuck.lever@oracle.com \
    --cc=kernel-tls-handshake@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.