Page MenuHomeFreeBSD

nvmft: Defer datamove operations to a pool of taskqueue threads
ClosedPublic

Authored by jhb on Sep 5 2024, 9:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 1 2024, 7:41 PM
Unknown Object (File)
Sep 24 2024, 8:16 PM
Unknown Object (File)
Sep 23 2024, 7:12 AM
Unknown Object (File)
Sep 16 2024, 10:04 AM
Unknown Object (File)
Sep 15 2024, 9:36 PM
Unknown Object (File)
Sep 11 2024, 11:09 AM
Unknown Object (File)
Sep 9 2024, 6:04 AM
Unknown Object (File)
Sep 8 2024, 5:40 PM
Subscribers

Details

Summary

Some block devices may request datamove operations from an ithread
context while holding locks. Queue datamove operations to a taskqueue
backed by a thread pool to safely permit blocking allocations, etc. in
datamove handling.

Sponsored by: Chelsio Communications

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Sep 5 2024, 9:09 PM

NB: The iSCSI frontend just uses M_NOWAIT in all its datamove handling instead, but that seems non-ideal to me as that adds lots of places to do error checking.

sys/dev/nvmf/controller/ctl_frontend_nvmf.c
604

The task queues for the CTL backends reuse control_softc->ctl_proc as the process to "hold" their taskqueue threads. Here we just create kthreads inside of the "kernel" process. It would be a simple change to move these into the "ctl" process which might be a cleaner accounting, but I'm not sure how gross of a layering violation it is for a frontend to access control_softc.

I don't know this area of code, but your changes LGTM. At least, I can't spot anything wrong with the locking or error handling.

This revision is now accepted and ready to land.Sep 6 2024, 2:14 PM