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

[Xixin Liu]

Hi Hannes,

Thanks for the feedback — I ran the lockdep and perf checks you suggested.

try_send vs send_all (lockdep)
------------------------------
With PROVE_LOCKING=y, blktests nvme/062:

  Inline nvme_tcp_try_send() instead of send_all() does *not* fix the
  lockdep splat: TLS would still call tls_sw_sendmsg() from queue_rq
  under blk_mq srcu — same as you suspected.

Performance / latency (skip TLS inline send)
----------------------------------------------
Same-machine nvmet-tcp with TLS (lockdep disabled for timing).  Compared
inline send_all (baseline) vs skipping inline send for TLS (io_work).
fio randwrite 4k, direct I/O:

  - iodepth=128, 8 jobs, 30s: ~90k IOPS baseline vs deferred after
    baseline warmup; no regression.

  - iodepth=1, 1 job, 30s (3 runs, warmup discarded): mean ~786us
    vs ~764us, p99 ~1.39ms on both sides.

  - 20x (connect --tls, one 4k write, disconnect): ~917ms vs ~897ms
    mean; dominated by TLS handshake, no measurable difference.

If the above is not enough on the latency side, I would be happy to
run other workloads you suggest.

Thanks,
Xixin Liu