Re: [RFC 3/3] ksmbd: use splice payloads for simple SMB2 READ

[Namjae Jeon]

On Mon, Jul 13, 2026 at 4:18 PM wang zhaolong <wangzhaolong@xxxxxxxxx> wrote:
>
> From: Wang Zhaolong <wangzhaolong@xxxxxxxxx>
Hi Wang,

Could you rebase the series on the current #ksmbd-for-next-next branch
to test this ?
>
> Use the page-backed payload path for plain TCP SMB2 READ requests of at
> least 64 KiB.
Could you provide benchmark results ? and requests smaller than 64 KiB
are unlikely to benefit from this optimization? Theoretically, it
seems like it would improve, but I am wondering how much performance
improvement there actually is.

> Unsupported collection results fall back before response
> ownership is committed; permission, locking and allocation failures retain
> the existing error handling.
>
> Keep signed, encrypted, compressed, compound and RDMA requests on the
> buffered path because they require signing, response transforms, compound
> response layout, or alternate transport handling. Streams, non-regular
> files, O_DIRECT and DAX reads also remain on the buffered path.
>
> Signed-off-by: Wang Zhaolong <wangzhaolong@xxxxxxxxx>
> ---
>  fs/smb/server/smb2pdu.c | 67 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
>
> diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
> index b73167785e87..a4a80ecc6d2f 100644
> --- a/fs/smb/server/smb2pdu.c
> +++ b/fs/smb/server/smb2pdu.c
> @@ -7304,10 +7304,38 @@ static ssize_t smb2_read_rdma_channel(struct ksmbd_work *work,
>                 return err;
>
>         return length;
>  }
>
> +#define KSMBD_READ_PAYLOAD_MIN_IO_SIZE SZ_64K
> +
> +static bool smb2_read_payload_allowed(struct ksmbd_work *work,
> +                                     struct smb2_read_req *req,
> +                                     struct ksmbd_file *fp,
> +                                     size_t length, bool is_rdma_channel)
> +{
> +       struct ksmbd_conn *conn = work->conn;
> +       struct file *filp = fp->filp;
> +
> +       if (is_rdma_channel || length < KSMBD_READ_PAYLOAD_MIN_IO_SIZE ||
> +           !conn->transport->ops->write_read_payload)
> +               return false;
> +       if (req->Flags & SMB2_READFLAG_REQUEST_COMPRESSED)
> +               return false;
> +       if (work->next_smb2_rcv_hdr_off || le32_to_cpu(req->hdr.NextCommand))
> +               return false;
> +       if (work->encrypted)
> +               return false;
> +       if (work->sess &&
> +           (work->sess->sign || conn->ops->is_sign_req(work, SMB2_READ_HE)))
> +               return false;
> +       if (ksmbd_stream_fd(fp) || !S_ISREG(file_inode(filp)->i_mode) ||
> +           (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp)))
Since ksmbd does not currently open files with O_DIRECT, is the
O_DIRECT check needed here, or is it only intended as a defensive
guard for future support?