blktests nvme/062 lockdep — defer TLS inline send to io_work?

[Xixin Liu]

Hi Hannes,

On Mon, 29 Jun 2026, Hannes Reinecke wrote:
> The most likely testcase showing regressions would be having as many
> jobs as your machine has CPUs and use qd=1.
> Just a single job will not be enough to show a noticeable difference.

I re-ran the TLS perf comparison with one job per CPU and queue depth 1
on a new test host.  Please treat the results below as the authoritative
perf data for this workload.

Test setup
----------
  aarch64 server, 128 CPUs, linux-next 7.2.0-rc1-*-perf-dirty

  Same-machine nvmet-tcp with TLS; target backing store is a 32G file on a
  local NVMe SSD.  fio runs against the connected nvme-tcp namespace.

  Compared inline send_all (baseline) vs deferring TLS inline send (io_work).
  fio randwrite 4k, direct I/O, 30s per run, 15s warmup discarded before
  each mode (10 runs total):

  - iodepth=1, numjobs=128:
      baseline 54539.4 IOPS, mean 2.34ms, p99 6.02ms
      patched  54529.0 IOPS, mean 2.34ms, p99 5.99ms

  - iodepth=128, numjobs=8:
      baseline 54632.6 IOPS, mean 18.74ms, p99 47.08ms
      patched  54633.6 IOPS, mean 18.74ms, p99 46.92ms

So on a 128-CPU box with the workload you called out, deferring TLS inline
send still looks neutral across 10 consecutive runs after warmup.

Thanks,
Xixin Liu