Re: [RFC 0/6] scsi: scsi transport for ufs devices
On Mon, 2018-07-30 at 14:52 -0400, Douglas Gilbert wrote: > I designed 'struct sg_io_v4' found in include/uapi/linux/bsg.h to handle > storage > related protocols, not just the SCSI command set. After the guard, the next > two fields in that structure are: > __u32 protocol; /* [i] 0 -> SCSI , */ > __u32 subprotocol; /* [i] 0 -> SCSI command, 1 -> SCSI task > management function, */ > > So there is lots of room for other protocols. Hi Doug, That's great, but it seems like most bsg drivers use other data structures than struct sg_io_v4. See e.g. struct fc_bsg_request and struct fc_bsg_reply in include/uapi/scsi/scsi_bsg_fc.h. See also struct iscsi_bsg_request and struct iscsi_bsg_reply in include/scsi/scsi_bsg_iscsi.h. The output of git grep -nH ' = job->request;' did not reveal any bsg driver that uses struct sg_io_v4. Did I perhaps misunderstand something? Thanks, Bart.
RE: [RFC 0/6] scsi: scsi transport for ufs devices
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org > On Behalf Of Douglas Gilbert > Sent: Monday, July 30, 2018 9:53 PM > To: Hannes Reinecke ; Bart Van Assche > ; h...@lst.de; j...@linux.vnet.ibm.com; linux- > s...@vger.kernel.org; jthumsh...@suse.de; martin.peter...@oracle.com; > Avri Altman > Cc: Vinayak Holikatti ; Avi Shchislowski > ; Alex Lemberg ; > Stanislav Nijnikov ; subha...@codeaurora.org > Subject: Re: [RFC 0/6] scsi: scsi transport for ufs devices > > On 2018-07-30 02:13 PM, Hannes Reinecke wrote: > > On 07/30/2018 08:01 PM, Bart Van Assche wrote: > >> On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote: > >>> Here is a proposal to use the scsi transport subsystem to manage > >>> ufs devices. > >>> > >>> scsi transport is a framework that allow to send scsi commands to > >>> a non-scsi devices. Still, it is flexible enough to allow > >>> sending non-scsi commands as well. We will use this framework to > >>> manage ufs devices by sending UPIU transactions. > >>> > >>> We added a new scsi transport module, a ufs-bsg LLD companion, > >>> and some new API to the ufs driver. > >> > >> My understanding is that all upstream code uses the bsg interface for > *SCSI* > >> commands. Sending UPIU commands over a bsg interface seems like > abuse of that > >> interface to me. Aren't you opening a can of worms with such an > approach? > >> > > I beg to disagree. > > > > bsg was precisely designed to handle non-SCSI commands, as this was the > main > > limitation of the original 'sg' interface. > > The original intention was to allow sending of transport frames for the > various > > SCSI transports (like FC or SAS), but there is no direct requirement for > > bsg to > > be limited to SCSI. > > Quite the contrary. > > I designed 'struct sg_io_v4' found in include/uapi/linux/bsg.h to handle > storage > related protocols, not just the SCSI command set. After the guard, the next > two fields in that structure are: > __u32 protocol; /* [i] 0 -> SCSI , */ > __u32 subprotocol; /* [i] 0 -> SCSI command, 1 -> SCSI task > management function, */ > > So there is lots of room for other protocols. Also the naming of fields is in > terms of request, response, data-in and data-out rather than SCSI command > specific terms (e.g. SCSI sense data maps to the response, while the SCSI > status is returned via a layered error mechanism). It also handles bidi data > transfers (which the sg_io_v3 interface does not). > > > NVMe didn't exist when struct sg_io_v4 was designed. If it was then I would > have made provisions for "metadata" transfers. One use for metadata > transfer might be to send protection information separately (i.e. as > metadata) rather than interleave with the user data as SCSI does. Is > NVMe metadata much used? And the extreme case: > bidi_data+bidi_metadata, > any examples of that? > > Doug Gilbert OK then. Let's give it a try. Will re-send it as patchset. Thanks, Avri
Re: [RFC 0/6] scsi: scsi transport for ufs devices
On 2018-07-30 02:13 PM, Hannes Reinecke wrote: On 07/30/2018 08:01 PM, Bart Van Assche wrote: On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote: Here is a proposal to use the scsi transport subsystem to manage ufs devices. scsi transport is a framework that allow to send scsi commands to a non-scsi devices. Still, it is flexible enough to allow sending non-scsi commands as well. We will use this framework to manage ufs devices by sending UPIU transactions. We added a new scsi transport module, a ufs-bsg LLD companion, and some new API to the ufs driver. My understanding is that all upstream code uses the bsg interface for *SCSI* commands. Sending UPIU commands over a bsg interface seems like abuse of that interface to me. Aren't you opening a can of worms with such an approach? I beg to disagree. bsg was precisely designed to handle non-SCSI commands, as this was the main limitation of the original 'sg' interface. The original intention was to allow sending of transport frames for the various SCSI transports (like FC or SAS), but there is no direct requirement for bsg to be limited to SCSI. Quite the contrary. I designed 'struct sg_io_v4' found in include/uapi/linux/bsg.h to handle storage related protocols, not just the SCSI command set. After the guard, the next two fields in that structure are: __u32 protocol; /* [i] 0 -> SCSI , */ __u32 subprotocol; /* [i] 0 -> SCSI command, 1 -> SCSI task management function, */ So there is lots of room for other protocols. Also the naming of fields is in terms of request, response, data-in and data-out rather than SCSI command specific terms (e.g. SCSI sense data maps to the response, while the SCSI status is returned via a layered error mechanism). It also handles bidi data transfers (which the sg_io_v3 interface does not). NVMe didn't exist when struct sg_io_v4 was designed. If it was then I would have made provisions for "metadata" transfers. One use for metadata transfer might be to send protection information separately (i.e. as metadata) rather than interleave with the user data as SCSI does. Is NVMe metadata much used? And the extreme case: bidi_data+bidi_metadata, any examples of that? Doug Gilbert
Re: [RFC 0/6] scsi: scsi transport for ufs devices
On 07/30/2018 08:01 PM, Bart Van Assche wrote: On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote: Here is a proposal to use the scsi transport subsystem to manage ufs devices. scsi transport is a framework that allow to send scsi commands to a non-scsi devices. Still, it is flexible enough to allow sending non-scsi commands as well. We will use this framework to manage ufs devices by sending UPIU transactions. We added a new scsi transport module, a ufs-bsg LLD companion, and some new API to the ufs driver. My understanding is that all upstream code uses the bsg interface for *SCSI* commands. Sending UPIU commands over a bsg interface seems like abuse of that interface to me. Aren't you opening a can of worms with such an approach? I beg to disagree. bsg was precisely designed to handle non-SCSI commands, as this was the main limitation of the original 'sg' interface. The original intention was to allow sending of transport frames for the various SCSI transports (like FC or SAS), but there is no direct requirement for bsg to be limited to SCSI. Quite the contrary. Cheers, Hannes
Re: [RFC 0/6] scsi: scsi transport for ufs devices
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote: > Here is a proposal to use the scsi transport subsystem to manage > ufs devices. > > scsi transport is a framework that allow to send scsi commands to > a non-scsi devices. Still, it is flexible enough to allow > sending non-scsi commands as well. We will use this framework to > manage ufs devices by sending UPIU transactions. > > We added a new scsi transport module, a ufs-bsg LLD companion, > and some new API to the ufs driver. My understanding is that all upstream code uses the bsg interface for *SCSI* commands. Sending UPIU commands over a bsg interface seems like abuse of that interface to me. Aren't you opening a can of worms with such an approach? Bart.
[RFC 0/6] scsi: scsi transport for ufs devices
Here is a proposal to use the scsi transport subsystem to manage ufs devices. scsi transport is a framework that allow to send scsi commands to a non-scsi devices. Still, it is flexible enough to allow sending non-scsi commands as well. We will use this framework to manage ufs devices by sending UPIU transactions. We added a new scsi transport module, a ufs-bsg LLD companion, and some new API to the ufs driver. For the time being, we will not use it for data transfer, but just for device management per-se. We are planning to add this capability in the future. We tested it on a Hikey-960 platform with a V4.14 kernel, "modernized" by recent bsg and ufs patches. We also used a htc11 with a V4.4 kernel, but needed much more transport/bsg/ufs patches to make it relevant. Avri Altman (6): scsi: Add ufs transport class scsi: ufs: Add ufs-bsg module scsi: ufs: Instantiate a ufs transport if its available scsi: ufs: Add API to execute raw upiu commands scsi: ufs-bsg: Add support for raw upiu in ufs_bsg_request() scsi: ufs-bsg: Add support for uic commands in ufs_bsg_request() drivers/scsi/Kconfig | 13 ++ drivers/scsi/Makefile | 1 + drivers/scsi/scsi_transport_ufs.c | 337 ++ drivers/scsi/ufs/Makefile | 1 + drivers/scsi/ufs/ufs_bsg.c| 292 + drivers/scsi/ufs/ufs_bsg.h| 76 + drivers/scsi/ufs/ufshcd.c | 232 ++ drivers/scsi/ufs/ufshcd.h | 4 + include/scsi/scsi_transport_ufs.h | 40 + include/uapi/scsi/scsi_bsg_ufs.h | 56 +++ 10 files changed, 1052 insertions(+) create mode 100644 drivers/scsi/scsi_transport_ufs.c create mode 100644 drivers/scsi/ufs/ufs_bsg.c create mode 100644 drivers/scsi/ufs/ufs_bsg.h create mode 100644 include/scsi/scsi_transport_ufs.h create mode 100644 include/uapi/scsi/scsi_bsg_ufs.h -- 1.9.1
