[PATCH net-next v2] Documentation: net/smc: correct old value of smcr_max_recv_wr

[PATCH net-next v2] Documentation: net/smc: correct old value of smcr_max_recv_wr

[Mahanta Jambigi]

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.

Fixes: aef3cdb47bbb net/smc: make wr buffer count configurable
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>
---
v2: Addressed few minor comments from Alexandra Winter.
---
 Documentation/networking/smc-sysctl.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst
index a8b4f357174e..93cc6244f6c8 100644
--- a/Documentation/networking/smc-sysctl.rst
+++ b/Documentation/networking/smc-sysctl.rst
@@ -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
-- 
2.51.0

Re: [PATCH net-next v2] Documentation: net/smc: correct old value of smcr_max_recv_wr

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 24 Apr 2026 07:23:36 +0200 you wrote:
> 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.
> 
> Fixes: aef3cdb47bbb net/smc: make wr buffer count configurable
> 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>
> 
> [...]

Here is the summary with links:
  - [net-next,v2] Documentation: net/smc: correct old value of smcr_max_recv_wr
    https://git.kernel.org/netdev/net-next/c/790ead939486

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html