Re: DIF/DIX issue related to config CONFIG_SCSI_MQ_DEFAULT

From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: John Garry <john.garry@huawei.com>
Cc: Ming Lei <ming.lei@redhat.com>,
	"chenxiang \(M\)" <chenxiang66@hisilicon.com>,
	"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-block\@vger.kernel.org" <linux-block@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>,
	Steffen Maier <maier@linux.ibm.com>
Subject: Re: DIF/DIX issue related to config CONFIG_SCSI_MQ_DEFAULT
Date: Mon, 03 Dec 2018 22:55:25 -0500	[thread overview]
Message-ID: <yq1k1kqt07m.fsf@oracle.com> (raw)
In-Reply-To: <e0e07583-98ca-4fc5-e60d-055e5474c084@huawei.com> (John Garry's message of "Fri, 30 Nov 2018 11:26:07 +0000")

Hi John,

> We have also noticed that if we just enable DIF in hisi_sas (with MQ),
> and not DIX, then no issue.

Enabling DIF doesn't really do anything on the kernel side other than
setting PROTECT=1 in the READ/WRITE CDB and telling the driver which DIX
protection operation the HBA should use. Since protection information is
invisible to the kernel and only sent on the wire between initiator and
target, enabling DIF doesn't really have the ability to interfere with
anything on the kernel side. We're basically just setting flags asking
HBA and storage to enable protected transfers.

> I did also noticed mail "[PATCH v2 01/23] zfcp: make DIX experimental,
> disabled, and independent of DIF", where DIX is made experimental.

...for the zfcp driver on zSeries.

Just nitpicking on terminology here:

T10 Protection Information (formerly known as DIF) describes how to
generate and verify 8 bytes of extra information that's sent trailing
each logical block on the wire between an initiator and target. The T10
PI spec is focused on the target device implementation of this and
largely ignores the initiator side.

DIX tries to remedy this deficiency. It is a spec that describes a set
of logical operations an initiator must implement to facilitate sending
and receiving the T10 protection information to/from host memory instead
of terminating it at the HBA. The DIX spec isn't experimental, it's
about a decade old and hasn't changed in years.

The Linux kernel support for data integrity passthrough in the block
layer and SCSI isn't experimental either. It's also a decade old and
used extensively in production.

So I object to the notion of "DIX being made experimental". An
ASIC/firmware/driver implementation of DIX may be experimental. And of
course I can't rule out regressions in the kernel block integrity
implementation as a result of some of the recent MQ changes (will be
happy to work with you guys to figure those out).

But DIX isn't experimental, nor is the kernel support for passing
protection information to an HBA.

> For now we may not support DIX. It seems to have issues. We wanted to
> try 3008 card on our system, but it does not seem to support DIX 0-3.

For some reason Broadcom have not upstreamed their DIX support. It's
supposedly available in their outbox driver.

-- 
Martin K. Petersen	Oracle Linux Engineering