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

Hi Namjae,

Thank you for the quick review.

> From: "Namjae Jeon"<[email protected]>
> Date:  Mon, Jul 13, 2026, 4:59 PM
> Subject:  Re: [RFC 3/3] ksmbd: use splice payloads for simple SMB2 READ
> To: "wang zhaolong"<[email protected]>
> Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
> On Mon, Jul 13, 2026 at 4:18 PM wang zhaolong <[email protected]> wrote:
> >
> > From: Wang Zhaolong <[email protected]>
> Hi Wang,
> 
> Could you rebase the series on the current #ksmbd-for-next-next branch
> to test this ?

Okay, I will rebase the series onto the current ksmbd-for-next-next branch and rerun
the functional and performance tests.

> >
> > 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.

Regarding the 64 KiB threshold, it is currently a conservative value rather than
a conclusion based on complete measurements. As noted in the cover letter,
I have already included initial results based on 1 MiB sequential reads, where
the splice path showed a clear improvement:

                            baseline    patched     delta
  bandwidth                 1.728 GB/s  2.246 GB/s  +30.0%
  mean completion latency   604.1 us    464.5 us    -23.1%
  median sample P99 latency 794.6 us    606.2 us    -23.7%

These results were obtained in a QEMU environment with ksmbd and the SMB
client in the same guest, using a warm 4 GiB file, SMB 3.1.1, cache=none, 1 MiB
synchronous reads, and one job.

I agree that smaller requests may also benefit. However, for small reads, the
overhead of managing pages and pipes might cancel out some of the gains
from reducing copies, so I chose 64 KiB as a conservative starting threshold.

I will add benchmarks for a range of request sizes, for example 4 KiB, 16 KiB, 32 KiB,
64 KiB, 128 KiB, 256 KiB, and 1 MiB. Based on those results, I can either adjust the
threshold or remove it if the splice path remains beneficial for smaller requests.

> > +               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?
> 

The O_DIRECT check is currently only a defensive guard. I added it
to ensure that the page-cache-backed payload path is not accidentally
used if direct-I/O support or another file-opening mode is introduced later.

I can remove the check if you prefer to avoid guarding an unsupported
configuration, or keep it with a comment explaining that it is intended for
future-proofing.

Best regards,
Wang Zhaolong