All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	target-devel@vger.kernel.org,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC] Simlify dif_verify routines and fixup fileio protection information code.
Date: Thu, 16 Apr 2015 18:58:38 +0300	[thread overview]
Message-ID: <552FDC2E.7020203@dev.mellanox.co.il> (raw)
In-Reply-To: <CAC5umygHt_LHyCWEhg9whhe7PfQBy=Y9uXbKAE6+1EL7MEzmrg@mail.gmail.com>

On 4/16/2015 4:46 PM, Akinobu Mita wrote:
> 2015-04-16 17:52 GMT+09:00 Sagi Grimberg <sagig@dev.mellanox.co.il>:
>> On 4/15/2015 7:10 PM, Martin K. Petersen wrote:
>>>>>>>>
>>>>>>>> "Sagi" == Sagi Grimberg <sagig@dev.mellanox.co.il> writes:
>>>
>>>
>>>>>> By the commit 436f4a0a ("loopback: Add fabric_prot_type attribute
>>>>>> support"), When WRITE_SAME command with WRPROTECT=0 is executed,
>>>>>> sbc_dif_generate() is called but cmd->t_prot_sg is NULL as block
>>>>>> layer didn't allocate it for WRITE_SAME.
>>>
>>>
>>> Sagi> Actually this is a bug. Why didn't the initiator allocate
>>> Sagi> integrity meta-data for WRITE_SAME? Looking at the code it looks
>>> Sagi> like it should.
>>>
>>> We don't issue WRITE SAME with PI so there is no prot SGL.
>>>
>>
>> Is there a specific reason why we don't?
>
> It is not only for the WRITE SAME requests from block device but
> also for READ/WRITE with PROTECT=0 requests by SG_IO.
>

This is specific to loopback which is using target_submit_cmd_map_sgls()
Other fabrics would allocate sgls per IO and the core would allocate
protection SGLs as well.

> So isn't is appropreate to allocate prot SGL in
> target_write_prot_action() (and mark se_cmd->se_cmd_flags to release
> it at deallocation time)?
>

I'd say that given this is specific to loopback, than tcm_loop needs
to be fixed... But specifically for WRITE_SAME, I'd be careful with
allocating a single 8 byte protection buffer because as Martin said,
unlike the data block, the protection field may change from sector to
sector (ref_tag in Type 1).

So allocating a single 8 byte buf will take it's toll in the backend
(iblock backend would need to allocate all the protection information
and add it to the bio anyway, file/rd will need to do multiple writes).

It might be better that for the special WRITE_SAME case, allocate 8 *
sectors sgl and set it up (incrementing ref_tag for type 1). This way,
the backend code can stay the same (other than opening write_same with
PI in iblock).

Sagi.

  parent reply	other threads:[~2015-04-16 15:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 17:19 [RFC] Simlify dif_verify routines and fixup fileio protection information code Sagi Grimberg
2015-04-13 17:19 ` [PATCH RFC 1/2] target: Merge sbc_verify_dif_read|write Sagi Grimberg
2015-04-13 17:19 ` [PATCH RFC 2/2] target/file: Remove fd_prot bounce buffer Sagi Grimberg
2015-04-14  1:23 ` [RFC] Simlify dif_verify routines and fixup fileio protection information code Martin K. Petersen
2015-04-14 12:17 ` Akinobu Mita
2015-04-14 17:20   ` Sagi Grimberg
2015-04-14 23:52     ` Akinobu Mita
2015-04-15 10:07       ` Sagi Grimberg
2015-04-15 14:16         ` Akinobu Mita
2015-04-15 14:33           ` Sagi Grimberg
2015-04-15 15:05             ` Martin K. Petersen
2015-04-15 15:08             ` Sagi Grimberg
2015-04-15 16:10               ` Martin K. Petersen
2015-04-16  8:52                 ` Sagi Grimberg
2015-04-16 13:46                   ` Akinobu Mita
2015-04-16 15:30                     ` Martin K. Petersen
2015-04-16 15:58                     ` Sagi Grimberg [this message]
2015-04-16 16:04                       ` Sagi Grimberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=552FDC2E.7020203@dev.mellanox.co.il \
    --to=sagig@dev.mellanox.co.il \
    --cc=akinobu.mita@gmail.com \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.