On Tue, 2013-11-05 at 11:13 +0200, Sagi Grimberg wrote:
> 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.
> 

The point is that changing the description from what the patch actually
does, to something it does not do in order to 'stay as close as possible
to the terminology of the SPC-4 standard' is pointlessly confusing.

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

Reply via email to