Documentation: net/smc: correct old value of smcr_max_recv_wr

The smc-sysctl.rst documentation incorrectly stated that
the previous hardcoded maximum number of WR buffers on
the receive path (smcr_max_recv_wr) was 16.
The correct historical value used before the introduction of
the sysctl control was 48. Update the documentation to reflect
the accurate historical value. Also fix a couple of minor typos.

Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Link: https://patch.msgid.link/20260424052336.3262350-1-mjambigi@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Mahanta Jambigi 2026-04-24 07:23:36 +02:00 committed by Jakub Kicinski
parent 254f49634e
commit 790ead9394

View File

@ -86,7 +86,7 @@ smcr_max_send_wr - INTEGER
Please be aware that all the buffers need to be allocated as a physically
continuous array in which each element is a single buffer and has the size
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
with half of the buffer count until it is ether successful or (unlikely)
with half of the buffer count until it is either successful or (unlikely)
we dip below the old hard coded value which is 16 where we give up much
like before having this control.
@ -100,14 +100,14 @@ smcr_max_recv_wr - INTEGER
depending on the workload it can be a bottleneck in a sense that threads
have to wait for work request buffers to become available. Before the
introduction of this control the maximal number of work request buffers
available on the receive path used to be hard coded to 16. With this control
available on the receive path used to be hard coded to 48. With this control
it becomes configurable. The acceptable range is between 2 and 2048.
Please be aware that all the buffers need to be allocated as a physically
continuous array in which each element is a single buffer and has the size
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
with half of the buffer count until it is ether successful or (unlikely)
we dip below the old hard coded value which is 16 where we give up much
with half of the buffer count until it is either successful or (unlikely)
we dip below the old hard coded value which is 48 where we give up much
like before having this control.
Default: 48