RFC nvmet: implement target passthru commands support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 of 8 patches 0 repliesNew
3 of 8 patches are in this archive. The cover letter announces 8.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/8 | nvme-core: add new interfaces | +0 | 0 replies | |
| 4/8 | nvmet: use const values for id-ctrl | +0 | 0 replies | |
| 8/8 | nvmet: add configfs interface for target passthru | +0 | 2 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/8] nvmet: implement target passthru commands support
Quoted 5 lines · Sagi Grimberg
So for normal IO commands, I would simply move the bio construction loop to shared code and call it from either the normal nvmet_execute_* or
nvmet_execute_passthru_io_cmd. I still don't understand what that buys us... I guess one benefit would be to utilize ranged (merged) discards instead of executing them range by range...
What are "normal" I/O commands? There can be vendor defined I/O commands that can do all kinds of weird things the block layer can't do. Hell, there are plenty of NVMe defined I/O commands that map to nothing the block layer could deal with.
We'll need an implementation that can deal with anything thrown at it, and Chaitanya has written that (turns out that part looks fairly trivial, it's all the setup around it that is a bit of a mess).
Quoted 4 lines
For admin commands I would do something different though, why not simply exporting
__nvme_passthru_cmd(portion ofnvme_user_cmd) and simply call that with a bit of tweaks to the host memory layout. That would eliminate the re-code innvmet_execute_admin_cmd()Thoughts?
Why? Not really much simpler, probably much slower due to the synchronous nature, and it also requires reshuffling the on the wire format of the SQe into another form just to unpack it again.
Quoted 3 lines
We need code to exclude more than a single access to the same passthru controller (or subsystem in fact). Otherwise we might be exposing the user to lots of troubles...
Only to the same controller I think, and then only allow one fabrics controller to be created for it.
Quoted 7 lines
Its also odd that a namespace is given a passthru access to a controller. Maybe we need to add a configfs interface for passthru subsystems? (under subsystems/ we have passthru file that takes the controller name or subsystem id or something)
Then automatically all the namespaces of that controller will be exposed via the subsystem
Sounds reasonable.
Quoted 4 lines
So namespace management needs a mechanism to add the new namespace via the fabrics target. This would require adding an event client mechanism to nvme that will create that namespace in nvmet before issuing the AEN.
Yeah, for now we should simply disallow it. Unfortunatelt it turns out the whole NVMe architecture isn't really well suitable for any kind of tunneling.