[PATCH 0/2] smb:client/server/smbdirect: correct value for max_fragmented_recv_size

[PATCH 0/2] smb:client/server/smbdirect: correct value for max_fragmented_recv_size

[Stefan Metzmacher]

Hi,

here is one additional fix for the credit problems
in the client, it most likely happens when using
signing on rdma: 'rdma,sec=ntlmsspi' as mount options.

The problem is that we announce a large
max_fragmented_recv_size to the server, while we
don't have enough recv buffers to hold
the largest possible fragmented message.

For now we use the same logic as we are
currently using in the server:

max_fragmented_recv_size = (recv_credit_max * max_recv_size) / 2

There's a lot to improve here, but this makes sure
we're able talk to a peer without running out of credits
while transferring a message that uses the full
max_fragmented_recv_size.

The server patch is basically just cosmetic
explaining the logic we're are using.
Note the value of smb_direct_max_fragmented_recv_size
is never really used as smb_direct_prepare
recalculates max_fragmented_recv_size.

This applies on top of ksmbd-for-next

Stefan Metzmacher (2):
  smb: client: correct value for smbd_max_fragmented_recv_size
  smb: server: correct value for smb_direct_max_fragmented_recv_size

 fs/smb/client/smbdirect.c      | 19 +++++++++++++--
 fs/smb/server/transport_rdma.c | 42 ++++++++++++++++++++++++++++++++--
 2 files changed, 57 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH 1/2] smb: client: correct value for smbd_max_fragmented_recv_size

[Stefan Metzmacher]

When we download a file without rdma offload or get
a large directly enumeration from the server,
the server might want to send up to smbd_max_fragmented_recv_size
bytes, but if it is too large all our recv buffers
might already be moved to the recv_io.reassembly.list
and we're no longer able to grant recv credits.

The maximum fragmented upper-layer payload receive size supported

Assume max_payload_per_credit is
smbd_max_receive_size - 24 = 1340

The maximum number would be
smbd_receive_credit_max * max_payload_per_credit

                      1340 * 255 = 341700 (0x536C4)

The minimum value from the spec is 131072 (0x20000)

For now we use the logic we used in ksmbd before:
                (1364 * 255) / 2 = 173910 (0x2A756)

Fixes: 03bee01d6215 ("CIFS: SMBD: Add SMB Direct protocol initial values and constants")
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Long Li <longli@microsoft.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
---
 fs/smb/client/smbdirect.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c
index bb236f80b3c7..d44847c9d8fc 100644
--- a/fs/smb/client/smbdirect.c
+++ b/fs/smb/client/smbdirect.c
@@ -101,8 +101,23 @@ int smbd_send_credit_target = 255;
 /* The maximum single message size can be sent to remote peer */
 int smbd_max_send_size = 1364;
 
-/*  The maximum fragmented upper-layer payload receive size supported */
-int smbd_max_fragmented_recv_size = 1024 * 1024;
+/*
+ * The maximum fragmented upper-layer payload receive size supported
+ *
+ * Assume max_payload_per_credit is
+ * smbd_max_receive_size - 24 = 1340
+ *
+ * The maximum number would be
+ * smbd_receive_credit_max * max_payload_per_credit
+ *
+ *                       1340 * 255 = 341700 (0x536C4)
+ *
+ * The minimum value from the spec is 131072 (0x20000)
+ *
+ * For now we use the logic we used in ksmbd before:
+ *                 (1364 * 255) / 2 = 173910 (0x2A756)
+ */
+int smbd_max_fragmented_recv_size = (1364 * 255) / 2;
 
 /*  The maximum single-message size which can be received */
 int smbd_max_receive_size = 1364;
-- 
2.43.0

[PATCH 2/2] smb: server: correct value for smb_direct_max_fragmented_recv_size

[Stefan Metzmacher]

We should make it clear that we use this strange value
instead of hiding it in same code flow.

Note this value is mainly ignored currently,
as we do the calculation again with
the negotiated max_recv_size in smb_direct_prepare().
So this is only a cosmetic change in order to
avoid confusion.

In future we may change the logic and
adjust the number of recv buffers instead
of the max_fragmented_recv_size.

Cc: Namjae Jeon <linkinjeon@kernel.org>
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
---
 fs/smb/server/transport_rdma.c | 42 ++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c
index 188f6c9c07d6..fb36fb9d5214 100644
--- a/fs/smb/server/transport_rdma.c
+++ b/fs/smb/server/transport_rdma.c
@@ -70,8 +70,23 @@ static int smb_direct_send_credit_target = 255;
 /* The maximum single message size can be sent to remote peer */
 static int smb_direct_max_send_size = 1364;
 
-/*  The maximum fragmented upper-layer payload receive size supported */
-static int smb_direct_max_fragmented_recv_size = 1024 * 1024;
+/*
+ * The maximum fragmented upper-layer payload receive size supported
+ *
+ * Assume max_payload_per_credit is
+ * smb_direct_receive_credit_max - 24 = 1340
+ *
+ * The maximum number would be
+ * smb_direct_receive_credit_max * max_payload_per_credit
+ *
+ *                       1340 * 255 = 341700 (0x536C4)
+ *
+ * The minimum value from the spec is 131072 (0x20000)
+ *
+ * For now we use the logic we used before:
+ *                 (1364 * 255) / 2 = 173910 (0x2A756)
+ */
+static int smb_direct_max_fragmented_recv_size = (1364 * 255) / 2;
 
 /*  The maximum single-message size which can be received */
 static int smb_direct_max_receive_size = 1364;
@@ -2531,6 +2546,29 @@ static int smb_direct_prepare(struct ksmbd_transport *t)
 				  le32_to_cpu(req->max_receive_size));
 	sp->max_fragmented_send_size =
 		le32_to_cpu(req->max_fragmented_size);
+	/*
+	 * The maximum fragmented upper-layer payload receive size supported
+	 *
+	 * Assume max_payload_per_credit is
+	 * smb_direct_receive_credit_max - 24 = 1340
+	 *
+	 * The maximum number would be
+	 * smb_direct_receive_credit_max * max_payload_per_credit
+	 *
+	 *                       1340 * 255 = 341700 (0x536C4)
+	 *
+	 * The minimum value from the spec is 131072 (0x20000)
+	 *
+	 * For now we use the logic we used before:
+	 *                 (1364 * 255) / 2 = 173910 (0x2A756)
+	 *
+	 * We need to adjust this here in case the peer
+	 * lowered sp->max_recv_size.
+	 *
+	 * TODO: instead of adjusting max_fragmented_recv_size
+	 * we should adjust the number of available buffers,
+	 * but for now we keep the current logic.
+	 */
 	sp->max_fragmented_recv_size =
 		(sp->recv_credit_max * sp->max_recv_size) / 2;
 	sc->recv_io.credits.target = le16_to_cpu(req->credits_requested);
-- 
2.43.0

Re: [PATCH 2/2] smb: server: correct value for smb_direct_max_fragmented_recv_size

[Namjae Jeon]

> -/*  The maximum fragmented upper-layer payload receive size supported */
> -static int smb_direct_max_fragmented_recv_size = 1024 * 1024;
> +/*
> + * The maximum fragmented upper-layer payload receive size supported
> + *
> + * Assume max_payload_per_credit is
> + * smb_direct_receive_credit_max - 24 = 1340
> + *
> + * The maximum number would be
> + * smb_direct_receive_credit_max * max_payload_per_credit
> + *
> + *                       1340 * 255 = 341700 (0x536C4)
> + *
> + * The minimum value from the spec is 131072 (0x20000)
> + *
> + * For now we use the logic we used before:
> + *                 (1364 * 255) / 2 = 173910 (0x2A756)
> + */
> +static int smb_direct_max_fragmented_recv_size = (1364 * 255) / 2;
>
>  /*  The maximum single-message size which can be received */
>  static int smb_direct_max_receive_size = 1364;
> @@ -2531,6 +2546,29 @@ static int smb_direct_prepare(struct ksmbd_transport *t)
>                                   le32_to_cpu(req->max_receive_size));
>         sp->max_fragmented_send_size =
>                 le32_to_cpu(req->max_fragmented_size);
> +       /*
> +        * The maximum fragmented upper-layer payload receive size supported
> +        *
> +        * Assume max_payload_per_credit is
> +        * smb_direct_receive_credit_max - 24 = 1340
> +        *
> +        * The maximum number would be
> +        * smb_direct_receive_credit_max * max_payload_per_credit
> +        *
> +        *                       1340 * 255 = 341700 (0x536C4)
> +        *
> +        * The minimum value from the spec is 131072 (0x20000)
> +        *
> +        * For now we use the logic we used before:
> +        *                 (1364 * 255) / 2 = 173910 (0x2A756)
These comments explaining the calculation is currently duplicated in
both the global variable declaration and inside smb_direct_prepare().

> +        *
> +        * We need to adjust this here in case the peer
> +        * lowered sp->max_recv_size.
> +        *
> +        * TODO: instead of adjusting max_fragmented_recv_size
> +        * we should adjust the number of available buffers,
> +        * but for now we keep the current logic.
> +        */
>         sp->max_fragmented_recv_size =
>                 (sp->recv_credit_max * sp->max_recv_size) / 2;
>         sc->recv_io.credits.target = le16_to_cpu(req->credits_requested);
> --
> 2.43.0
>

Re: [PATCH 2/2] smb: server: correct value for smb_direct_max_fragmented_recv_size

[Stefan Metzmacher]

Am 06.02.26 um 16:09 schrieb Namjae Jeon:
>> -/*  The maximum fragmented upper-layer payload receive size supported */
>> -static int smb_direct_max_fragmented_recv_size = 1024 * 1024;
>> +/*
>> + * The maximum fragmented upper-layer payload receive size supported
>> + *
>> + * Assume max_payload_per_credit is
>> + * smb_direct_receive_credit_max - 24 = 1340
>> + *
>> + * The maximum number would be
>> + * smb_direct_receive_credit_max * max_payload_per_credit
>> + *
>> + *                       1340 * 255 = 341700 (0x536C4)
>> + *
>> + * The minimum value from the spec is 131072 (0x20000)
>> + *
>> + * For now we use the logic we used before:
>> + *                 (1364 * 255) / 2 = 173910 (0x2A756)
>> + */
>> +static int smb_direct_max_fragmented_recv_size = (1364 * 255) / 2;
>>
>>   /*  The maximum single-message size which can be received */
>>   static int smb_direct_max_receive_size = 1364;
>> @@ -2531,6 +2546,29 @@ static int smb_direct_prepare(struct ksmbd_transport *t)
>>                                    le32_to_cpu(req->max_receive_size));
>>          sp->max_fragmented_send_size =
>>                  le32_to_cpu(req->max_fragmented_size);
>> +       /*
>> +        * The maximum fragmented upper-layer payload receive size supported
>> +        *
>> +        * Assume max_payload_per_credit is
>> +        * smb_direct_receive_credit_max - 24 = 1340
>> +        *
>> +        * The maximum number would be
>> +        * smb_direct_receive_credit_max * max_payload_per_credit
>> +        *
>> +        *                       1340 * 255 = 341700 (0x536C4)
>> +        *
>> +        * The minimum value from the spec is 131072 (0x20000)
>> +        *
>> +        * For now we use the logic we used before:
>> +        *                 (1364 * 255) / 2 = 173910 (0x2A756)
> These comments explaining the calculation is currently duplicated in
> both the global variable declaration and inside smb_direct_prepare().

Yes, that's exactly what I wanted.

In my smbdirect.ko patches smb_direct_prepare() will be removed
and the comment moves to smbdirect_accept.c where there's no
direct link between them anymore.

I'd also like to keep this in order to remind me that
we need a more useful solution to this.

Windows offers a max fragmented size of 1048576 (0x100000)

metze

Re: [PATCH 0/2] smb:client/server/smbdirect: correct value for max_fragmented_recv_size

[Namjae Jeon]

On Fri, Feb 6, 2026 at 1:14 AM Stefan Metzmacher <metze@samba.org> wrote:
>
> Hi,
>
> here is one additional fix for the credit problems
> in the client, it most likely happens when using
> signing on rdma: 'rdma,sec=ntlmsspi' as mount options.
>
> The problem is that we announce a large
> max_fragmented_recv_size to the server, while we
> don't have enough recv buffers to hold
> the largest possible fragmented message.
>
> For now we use the same logic as we are
> currently using in the server:
>
> max_fragmented_recv_size = (recv_credit_max * max_recv_size) / 2
>
> There's a lot to improve here, but this makes sure
> we're able talk to a peer without running out of credits
> while transferring a message that uses the full
> max_fragmented_recv_size.
>
> The server patch is basically just cosmetic
> explaining the logic we're are using.
> Note the value of smb_direct_max_fragmented_recv_size
> is never really used as smb_direct_prepare
> recalculates max_fragmented_recv_size.
>
> This applies on top of ksmbd-for-next
>
> Stefan Metzmacher (2):
>   smb: client: correct value for smbd_max_fragmented_recv_size
>   smb: server: correct value for smb_direct_max_fragmented_recv_size
Acked-by: Namjae Jeon <linkinjeon@kernel.org>

Thanks!