UNMAP command parameter list

UNMAP command parameter list

[Andras Kovacs]

  Hi all,

  I'm trying to see what parameters are passed to the UFS driver from the
SCSI midlayer when an UNMAP command is issued. In the UFS driver I can see
the 10 byte command itself in the unsigned char *cmnd field of the struct
scsi_cmnd, and it tells me that the parameter list length is 24 bytes (an 8
byte UNMAP Parameter List header followed by one 16 byte long UNMAP Block
Descriptor), but I'm having trouble finding where this UNMAP Parameter List
is. It doesn't seem to be in the cmnd[] byte array after the UNMAP command
itself.

  Can anyone tell me where I can find the UNMAP Parameter List which belongs
to a particular UNMAP command?

  Any and all info would be greatly appreciated.

  Andras

RE: UNMAP command parameter list

[Elliott, Robert (Server Storage)]

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Andras Kovacs
> Sent: Friday, 07 November, 2014 5:30 PM
> To: linux-scsi@vger.kernel.org
> Subject: UNMAP command parameter list
> 
> 
>   Hi all,
> 
>   I'm trying to see what parameters are passed to the UFS driver from the
> SCSI midlayer when an UNMAP command is issued. In the UFS driver I can see
> the 10 byte command itself in the unsigned char *cmnd field of the struct
> scsi_cmnd, and it tells me that the parameter list length is 24 bytes (an 8
> byte UNMAP Parameter List header followed by one 16 byte long UNMAP Block
> Descriptor), but I'm having trouble finding where this UNMAP Parameter List
> is. It doesn't seem to be in the cmnd[] byte array after the UNMAP
> command itself.
> 
>   Can anyone tell me where I can find the UNMAP Parameter List which
> belongs to a particular UNMAP command?
> 
>   Any and all info would be greatly appreciated.
> 
>   Andras

That is the data transferred for the command, not in the
command descriptor block itself.

Typical T10 terminology is:
* parameter list = data-out buffer (i.e., write data)
* parameter data = data-in buffer (i.e., read data)


---
Rob Elliott    HP Server Storage

Re: UNMAP command parameter list

[Andras Kovacs]

Elliott, Robert (Server Storage <Elliott <at> hp.com> writes:

> That is the data transferred for the command, not in the
> command descriptor block itself.

Thank you. Then I guess I'll find the Paramerer List in the struct
scsi_data_buffer sdb variable (within struct scsi_cmnd). Will check on Monday.

Re: UNMAP command parameter list

[Andras Kovacs]

Andras Kovacs <akovacs <at> fixstars.com> writes:

> 
> Elliott, Robert (Server Storage <Elliott <at> hp.com> writes:
> 
> > That is the data transferred for the command, not in the
> > command descriptor block itself.
> 
> Thank you. Then I guess I'll find the Paramerer List in the struct
> scsi_data_buffer sdb variable (within struct scsi_cmnd). Will check on 
> Monday.

  I've looked into it, but struct scsi_data_buffer doesn't contain a byte
array (rather a struct sg_table variable and some housekeeping vars). So my
question is still: where can I find the Parameter List associated with a
particular UNMAP command?

Re: UNMAP command parameter list

[Martin K. Petersen]

>>>>> "Andras" == Andras Kovacs <akovacs@fixstars.com> writes:

>> Thank you. Then I guess I'll find the Paramerer List in the struct
>> scsi_data_buffer sdb variable (within struct scsi_cmnd). Will check
>> on Monday.

Andras> I've looked into it, but struct scsi_data_buffer doesn't contain
Andras> a byte array (rather a struct sg_table variable and some
Andras> housekeeping vars). So my question is still: where can I find
Andras> the Parameter List associated with a particular UNMAP command?

You'll have to traverse scatterlist and extract the descriptor from
there. You can use scsi_for_each_sg() to walk the list.

If you only care about in-kernel discards it's pretty easy since we only
issue a single descriptor. If you want to support arbitrary block pc
UNMAP commands you'll have to be able to deal with multiple descriptors
across multiple scatterlist elements. But the accessor macro makes that
easy so I suggest you take that approach.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: UNMAP command parameter list

[Christoph Hellwig]

On Mon, Nov 10, 2014 at 11:44:39AM -0500, Martin K. Petersen wrote:
> You'll have to traverse scatterlist and extract the descriptor from
> there. You can use scsi_for_each_sg() to walk the list.
> 
> If you only care about in-kernel discards it's pretty easy since we only
> issue a single descriptor. If you want to support arbitrary block pc
> UNMAP commands you'll have to be able to deal with multiple descriptors
> across multiple scatterlist elements. But the accessor macro makes that
> easy so I suggest you take that approach.

Note that if the hardware doesn't actually implement UNMAP and you have
to emulate something you're probably better off emulating WRITE SAME
(16) with the UNMAP bit, as the format is a lot easier to handle,
and it's much better specified to start with.

Re: UNMAP command parameter list

[Martin K. Petersen]

>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:

Christoph> Note that if the hardware doesn't actually implement UNMAP
Christoph> and you have to emulate something you're probably better off
Christoph> emulating WRITE SAME (16) with the UNMAP bit, as the format
Christoph> is a lot easier to handle, and it's much better specified to
Christoph> start with.

Yup, absolutely!

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: UNMAP command parameter list

[Andras Kovacs]

Christoph Hellwig <hch <at> infradead.org> writes:

> 
> On Mon, Nov 10, 2014 at 11:44:39AM -0500, Martin K. Petersen wrote:
> > You'll have to traverse scatterlist and extract the descriptor from
> > there. You can use scsi_for_each_sg() to walk the list.

  Thank you; I'm working on it.

> > 
> > If you only care about in-kernel discards it's pretty easy since we only
> > issue a single descriptor. If you want to support arbitrary block pc
> > UNMAP commands you'll have to be able to deal with multiple descriptors
> > across multiple scatterlist elements. But the accessor macro makes that
> > easy so I suggest you take that approach.
> 
> Note that if the hardware doesn't actually implement UNMAP and you have
> to emulate something you're probably better off emulating WRITE SAME
> (16) with the UNMAP bit, as the format is a lot easier to handle,
> and it's much better specified to start with.

  Actually, my case is that the HW (at least in its current iteration)
doesn't support WRITE SAME but does support UNMAP. But it seems that the
discard option given to ext4 at mount time is "ineffective" in the sense of
not keeping up a high write transfer rate to the device (it looks like write
amplification is happening, something which discard -- and UNMAP -- ought to
preempt). So now I'm writing code to 'debug' the UNMAP commands which get
passed to the device.