Skip to content

RFC SCSI Userspace Target

Mike Christie linux-scsi 1 version In review

Get series with b4
b4 am 1138157882.11692.31.camel@max

Versions newest first

  1. v1 RFC Latest3 patches 17 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3SCSI Userspace Target: scsi-ml changesdrivers/scsi/hosts.c drivers/scsi/scsi.c drivers/scsi/scsi_lib.c +4 more+151 -89 replies
2/3SCSI Userspace Target: scsi tgt core functionsdrivers/scsi/Kconfig drivers/scsi/Makefile drivers/scsi/scsi_tgt_lib.c +5 more+697 -00 replies
3/3SCSI Userspace Target: example target driverdrivers/scsi/iscsi_tcp_tgt.c+1941 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH RFC 0/3] SCSI Userspace Target

The following patches begin to add the infrastructure for the SCSI Userspace target framework. We were not sure about what James meant by some of his comments, so rather than getting to far we want to post a early.

As the email subject hints, the goal of the project is to push most of the target code to userspace. The only parts we kept in the kernel were for transferring data between the LLD and userpsace and the netlink interface. We included the relevant parts of a software iscsi target as an example.

We also just based ourselves off the scsi_host. This has the benefit of being able to reuse the scsi-ml host code and for HBAs that have a initiator and target mode, they only need to allocate a single scsi_host that corresponds to the PCI device, iscsi session, or whatever your LLD allocates it for. In theory, a single scsi_host can be used by the LLD for running both the target and initiator at the same time. The drawback is it prevents us from doing a more generic target framework that works for any block device (well, someone could do a libata type of target for any transport).

Just to be clear, so people do not pee their pants :) These patches are not ready for prime time. We feel we are at a good point, where we think we can continue building and allow others to help in the development if this basic infrastructure is ok.

There is no error handling yet (since we push so much to userspace it will not be much kernel code), the userspce code is still being reworked to tweak performance (the kernel code is too), we still need build proper scatterlists for HW LLDs (although we can do this with the scsi stuff that was just merged it is not very efficient (see commented code in scsi_tgt_lib.c)). We just want to make sure we are heading in the right direction. For example, should we be using the scsi_host or should we add our own data structure, is the perfomance drop Tomo reported earlier (he has new numbers and has more tweaks up his sleeve) really that acceptable or should we go to scst.

We are also up for discussing making the interface more generic, so we can one day do the scsi scanning and async event handling through it.

Thanks

Mike and Tomo