From mchristi@redhat.com Tue Aug 11 13:57:10 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164693A6BE4 for ; Tue, 11 Aug 2009 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1hdZEjCcCYN for ; Tue, 11 Aug 2009 13:57:06 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by core3.amsl.com (Postfix) with ESMTP id 54F443A6EA5 for ; Tue, 11 Aug 2009 13:57:03 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKuCdC021565; Tue, 11 Aug 2009 16:56:14 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7BKuB1F004715; Tue, 11 Aug 2009 16:56:12 -0400 Received: from [10.11.12.226] (vpn-12-226.rdu.redhat.com [10.11.12.226]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKuAvD002144; Tue, 11 Aug 2009 16:56:11 -0400 Message-ID: <4A81DAEA.8080403@redhat.com> Date: Tue, 11 Aug 2009 15:56:10 -0500 From: Mike Christie User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: ips@ietf.org, Hannes Reinecke , open-iscsi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [Ips] lun reset and r2t error handling X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:57:10 -0000 Hi, For a single connection session with ERL=0 and without FastAbort, if the initiator has sent a lun reset task management function and the target has sent a R2T, is it ok for the target to send a task management response with Function Complete, before the initiator has sent the data-out pdus for the R2T? It looks like the reason the target will do this is due to a internal target timeout (target did not get the data-outs within some timeout period). If the target does return the task management function with Function Complete, should the initiator continue to respond to the R2Ts? And one other question. In section 10.5.1, we have: The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible. Does this mean if we have sent a lun reset, and the target has sent a R2T, should we be setting the F-bit in the continued data-out PDU so as to end the transfer, even though actual data transfer has not been completed entirely? What if we do send all the data like normal, should that still be ok? From Julian_Satran@il.ibm.com Wed Aug 12 06:32:36 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B64E3A6909 for ; Wed, 12 Aug 2009 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0pNt41Osd35 for ; Wed, 12 Aug 2009 06:32:35 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 413EB3A6805 for ; Wed, 12 Aug 2009 06:32:35 -0700 (PDT) Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n7C3khQM005574 for ; Wed, 12 Aug 2009 03:46:43 GMT Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1507.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7C3khqf3301534 for ; Wed, 12 Aug 2009 05:46:43 +0200 Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n7C3kge8014654 for ; Wed, 12 Aug 2009 05:46:43 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n7C3kg7D014651; Wed, 12 Aug 2009 05:46:42 +0200 In-Reply-To: <4A81DAEA.8080403@redhat.com> References: <4A81DAEA.8080403@redhat.com> To: Mike Christie MIME-Version: 1.0 X-KeepSent: 3BD6AD19:DD34E8FC-C2257610:00145B55; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Julian Satran Message-ID: Date: Wed, 12 Aug 2009 06:46:41 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 12/08/2009 06:46:41, Serialize complete at 12/08/2009 06:46:41 Content-Type: multipart/alternative; boundary="=_alternative 0014BFBAC2257610_=" Cc: ips@ietf.org, open-iscsi , Hannes Reinecke Subject: Re: [Ips] lun reset and r2t error handling X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:32:36 -0000 This is a multipart message in MIME format. --=_alternative 0014BFBAC2257610_= Content-Type: text/plain; charset="US-ASCII" some answers in text ips-bounces@ietf.org wrote on 11/08/2009 23:56:10: > From: > > Mike Christie > > To: > > ips@ietf.org, Hannes Reinecke , open-iscsi iscsi@googlegroups.com> > > Date: > > 11/08/2009 23:57 > > Subject: > > [Ips] lun reset and r2t error handling > > Sent by: > > ips-bounces@ietf.org > > Hi, > > For a single connection session with ERL=0 and without FastAbort, if the > initiator has sent a lun reset task management function and the target > has sent a R2T, is it ok for the target to send a task management > response with Function Complete, before the initiator has sent the > data-out pdus for the R2T? It looks like the reason the target will do > this is due to a internal target timeout (target did not get the > data-outs within some timeout period). > > If the target does return the task management function with Function > Complete, should the initiator continue to respond to the R2Ts? > The initiator doesn't have to send more data but since more data may be still in flight it shouldn't harm to send a "terminating" Dataout. Target should behave OK in both cases. > And one other question. In section 10.5.1, we have: > > The issuing initiator SHOULD however terminate (i.e., by setting the > F-bit to 1) these response sequences as quickly as possible. > > Does this mean if we have sent a lun reset, and the target has sent a > R2T, should we be setting the F-bit in the continued data-out PDU so as > to end the transfer, even though actual data transfer has not been > completed entirely? Yes > > What if we do send all the data like normal, should that still be ok? Yes - receivers are supposed to be lenient. > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips --=_alternative 0014BFBAC2257610_= Content-Type: text/html; charset="US-ASCII" some answers in text

ips-bounces@ietf.org wrote on 11/08/2009 23:56:10:

> From:
>
> Mike Christie <mchristi@redhat.com>
>
> To:
>
> ips@ietf.org, Hannes Reinecke <hare@suse.de>, open-iscsi <open-
> iscsi@googlegroups.com>
>
> Date:
>
> 11/08/2009 23:57
>
> Subject:
>
> [Ips] lun reset and r2t error handling
>
> Sent by:
>
> ips-bounces@ietf.org
>
> Hi,
>
> For a single connection session with ERL=0 and without FastAbort, if the
> initiator has sent a lun reset task management function and the target
> has sent a R2T, is it ok for the target to send a task management
> response with Function Complete, before the initiator has sent the
> data-out pdus for the R2T? It looks like the reason the target will do
> this is due to a internal target timeout (target did not get the
> data-outs within some timeout period).
>
> If the target does return the task management function with Function
> Complete, should the initiator continue to respond to the R2Ts?
>


The initiator doesn't have to send more data but since more data may be still in flight
it shouldn't harm to send a "terminating" Dataout. Target should behave OK in both cases.

> And one other question. In section 10.5.1, we have:
>
>     The issuing initiator SHOULD however terminate (i.e., by setting the
>     F-bit to 1) these response sequences as quickly as possible.
>
> Does this mean if we have sent a lun reset, and the target has sent a
> R2T, should we be setting the F-bit in the continued data-out PDU so as
> to end the transfer, even though actual data transfer has not been
> completed entirely?
Yes
>
> What if we do send all the data like normal, should that still be ok?
Yes - receivers are supposed to be lenient.
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www.ietf.org/mailman/listinfo/ips
 --=_alternative 0014BFBAC2257610_=--