On 11/4/2013 8:41 PM, Nicholas A. Bellinger wrote:
On Sat, 2013-11-02 at 14:57 -0700, Bart Van Assche wrote:
On 1/11/2013 18:36, Nicholas A. Bellinger wrote:
On Fri, 2013-11-01 at 08:03 -0700, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
In T10-DIF, when a series of 512-byte data blocks are transferred, each
block is followed by an 8-byte guard. The guard consists of CRC that
protects the integrity of the data in the block, and some other tags
that protects against mis-directed IOs.
Shouldn't that read "logical block length divided by 2**(protection
interval exponent)" instead of "512" ? From the SPC-4 FORMAT UNIT
section:
Why should the protection interval in FORMAT_UNIT be mentioned when it's
not supported by the hardware, nor by drivers/scsi/sd_dif.c itself..?
Hello Nick,
My understanding is that this patch series is not only intended for
initiator drivers but also for target drivers like ib_srpt and ib_isert.
As you know target drivers do not restrict the initiator operating
system to Linux. Although I do not know whether there are already
operating systems that support the "protection interval exponent",
It's my understanding that Linux is still the only stack that supports
DIF, so AFAICT no one is actually supporting this.
I think it is a good idea to stay as close as possible to the terminology
of the SPC-4 standard.
No, in this context it only adds pointless misdirection because 1) The
hardware in question doesn't support it, and 2) Linux itself doesn't
support it.
I think that Bart is suggesting renaming block_size as pi_interval in
ib_sig_domain.
I tend to agree since even if support for that does not exist yet, it
might be in the future.
I think it is not a misdirection because it does represent the
protection information interval.
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
