From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Subject: Re: [PATCH 1/4] target/core: T10-Dif: check HW support capabilities
Date: Mon, 31 Mar 2014 18:19:06 -0700
Message-ID: <1396315146.22665.82.camel@haakon3.risingtidesystems.com>
References: <1396047927-14189-1-git-send-email-quinn.tran@qlogic.com>
	 <1396047927-14189-2-git-send-email-quinn.tran@qlogic.com>
	 <53360E54.5060004@mellanox.com>
	 <504EB66DAC8D234EB8E8560985C2D7AD46CE87D7@avmb2.qlogic.org>
	 <533620C0.9060903@mellanox.com>
	 <504EB66DAC8D234EB8E8560985C2D7AD46CE9B32@avmb2.qlogic.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-path: <target-devel-owner@vger.kernel.org>
In-Reply-To: <504EB66DAC8D234EB8E8560985C2D7AD46CE9B32@avmb2.qlogic.org>
Sender: target-devel-owner@vger.kernel.org
To: Quinn Tran <quinn.tran@qlogic.com>
Cc: sagi grimberg <sagig@mellanox.com>, "target-devel@vger.kernel.org" <target-devel@vger.kernel.org>, linux-scsi <linux-scsi@vger.kernel.org>, Giridhar Malavali <giridhar.malavali@qlogic.com>, Saurav Kashyap <saurav.kashyap@qlogic.com>, Andrew Vasquez <andrew.vasquez@qlogic.com>
List-Id: linux-scsi@vger.kernel.org

On Mon, 2014-03-31 at 17:53 +0000, Quinn Tran wrote:
> On 3/28/14 6:24 PM, "sagi grimberg" <sagig@mellanox.com> wrote:
> 
> >On 3/29/2014 3:53 AM, Quinn Tran wrote:

<SNIP>

> >>>> +            }
> >>>> +    }
> >>>> +
> >>>>       if (lun->lun_se_dev !=  NULL) {
> >>>>               pr_err("Port Symlink already exists\n");
> >>>>               return -EEXIST;
> >>>> diff --git a/drivers/target/target_core_tpg.c
> >>>> b/drivers/target/target_core_tpg.c
> >>>> index c036595..9279971 100644
> >>>> --- a/drivers/target/target_core_tpg.c
> >>>> +++ b/drivers/target/target_core_tpg.c
> >>>> @@ -632,6 +632,15 @@ int core_tpg_set_initiator_node_tag(
> >>>>    }
> >>>>    EXPORT_SYMBOL(core_tpg_set_initiator_node_tag);
> >>>>
> >>>> +void core_tpg_set_fabric_t10dif(
> >>>> +    struct se_portal_group *tpg,
> >>>> +    uint32_t fabric_t10dif_force_on)
> >>>> +{
> >>>> +    tpg->fabric_t10dif_force_on = fabric_t10dif_force_on;
> >>>> +}
> >>>> +EXPORT_SYMBOL(core_tpg_set_fabric_t10dif);
> >>>> +
> >>> Is there a user for this function in this patch?
> >> QT> I'm on the fence with this piece.  Just thinking of a case where DIX
> >> is not available for initiator side, but user wants to turn on
> >>protection
> >> at the link layer.  Our test folks would like to cover this case in the
> >> future.
> >
> >Not sure I understand. Initiator will send the target data+protection
> >(DIX disabled HBA does INSERT), why does this help?
> >Why should the target fabric care who generated the protection (OS or
> >HBA)?
> 
> QT> Sorry for the confusion.  The case I'm trying to get at is "Data In
> Insert" and "Data out strip".    In this case, the protection starts from
> front end target adapter to the back end storage.  In revisit your
> previous patch, this case is not covered.
> 
> 

<nod>

So for the TARGET_PROT_DIN_INSERT + TARGET_PROT_DOUT_STRIP cases, the
target will need to expose INQUIRY PROTECT=1 + other PI related control
bits when the fabric supports these modes, regardless of what PI is
supported on the backend device.

Keeping this configuration in mind as well while coding up the
aforementioned series.  ;)

--nab