All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	Mike Christie <michaelc@cs.wisc.edu>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	target-devel <target-devel@vger.kernel.org>,
	Oren Duer <oren@mellanox.com>,
	james.smart@emulex.com, Or Gerlitz <ogerlitz@mellanox.com>,
	cbm@chadalapaka.com, julians@infinidat.com, meth@il.ibm.com,
	david.black@emc.com
Subject: iSCSI Expected Data Transfer Length for T10-PI
Date: Sun, 25 May 2014 18:30:35 +0300	[thread overview]
Message-ID: <53820C9B.3090003@dev.mellanox.co.il> (raw)

Hey All,

Recently, iSER end-to-end T10-PI support maid it mainline.
I am wandering about the impact T10-PI should or shouldn't have on iSCSI 
header
field "Expected Data Transfer Length".

RFC-7143 states:
"the Expected Data Transfer Length field contains the number of bytes of 
data involved in this SCSI operation."
Since this field relates to *data bytes* I kept T10-PI implicit wrt this 
field. The iSCSI target calculates the
total transfer length (data + protection) from the cdb transfer length 
field and protect bits.

In FC, the fc_dl field was updated to relate to the total number of 
transfer bytes and includes
data and protection bytes. virtio_scsi was added with a header PI 
section (virtio_scsi_cmd_req_pi).

So my question is, should this field be updated to explicitly include 
T10-PI bytes like the FC equivalent fc_dl?
Or should T10-PI bytes be implicit?

I want to pin down this one to avoid a situation where the standard is 
open for interpretations.

Thanks,
Sagi.

             reply	other threads:[~2014-05-25 15:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 15:30 Sagi Grimberg [this message]
2014-05-25 19:39 ` iSCSI Expected Data Transfer Length for T10-PI Julian Satran
2014-05-25 21:04   ` Sagi Grimberg
2014-05-27 11:58 ` Black, David
2014-05-27 17:12   ` 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=53820C9B.3090003@dev.mellanox.co.il \
    --to=sagig@dev.mellanox.co.il \
    --cc=cbm@chadalapaka.com \
    --cc=david.black@emc.com \
    --cc=james.smart@emulex.com \
    --cc=julians@infinidat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=meth@il.ibm.com \
    --cc=michaelc@cs.wisc.edu \
    --cc=nab@linux-iscsi.org \
    --cc=ogerlitz@mellanox.com \
    --cc=oren@mellanox.com \
    --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.