| Message ID | 1532871206-6311-1-git-send-email-avri.altman@sandisk.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | scsi: scsi transport for ufs devices | expand |
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.
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
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
> -----Original Message----- > From: linux-scsi-owner@vger.kernel.org <linux-scsi-owner@vger.kernel.org> > On Behalf Of Douglas Gilbert > Sent: Monday, July 30, 2018 9:53 PM > To: Hannes Reinecke <hare@suse.com>; Bart Van Assche > <Bart.VanAssche@wdc.com>; hch@lst.de; jejb@linux.vnet.ibm.com; linux- > scsi@vger.kernel.org; jthumshirn@suse.de; martin.petersen@oracle.com; > Avri Altman <Avri.Altman@wdc.com> > Cc: Vinayak Holikatti <Vinayak.Holikatti@wdc.com>; Avi Shchislowski > <Avi.Shchislowski@wdc.com>; Alex Lemberg <Alex.Lemberg@wdc.com>; > Stanislav Nijnikov <Stanislav.Nijnikov@wdc.com>; subhashj@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
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.