Update the pipelining docs

Document the effect on the internal read buffer when using pipelining.

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19456)

diff --git a/doc/man3/SSL_CTX_set_split_send_fragment.pod b/doc/man3/SSL_CTX_set_split_send_fragment.pod
index 97ef0fde513922ac38fb39eec76b6ce56525d046..e8ac6edae4cdd9ce03507d9e36c6f3dd0acaae8d 100644 (file)
--- a/doc/man3/SSL_CTX_set_split_send_fragment.pod
+++ b/doc/man3/SSL_CTX_set_split_send_fragment.pod
@@ -56,7 +56,7 @@ of pipelines that will be used at any one time. This value applies to both
 used (i.e. normal non-parallel operation). The number of pipelines set must be
 in the range 1 - SSL_MAX_PIPELINES (32). Setting this to a value > 1 will also
 automatically turn on "read_ahead" (see L<SSL_CTX_set_read_ahead(3)>). This is
-explained further below. OpenSSL will only every use more than one pipeline if
+explained further below. OpenSSL will only ever use more than one pipeline if
 a cipher suite is negotiated that uses a pipeline capable cipher provided by an
 engine.
 
@@ -96,7 +96,10 @@ into the buffer. Without this set data is read into the read buffer one record
 at a time. The more data that can be read, the more opportunity there is for
 parallelising the processing at the cost of increased memory overhead per
 connection. Setting B<read_ahead> can impact the behaviour of the SSL_pending()
-function (see L<SSL_pending(3)>).
+function (see L<SSL_pending(3)>). In addition the default size of the internal
+read buffer is multiplied by the number of pipelines available to ensure that we
+can read multiple records in one go. This can therefore have a significant
+impact on memory usage.
 
 The SSL_CTX_set_default_read_buffer_len() and SSL_set_default_read_buffer_len()
 functions control the size of the read buffer that will be used. The B<len>