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.
next 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.