[storm] iSER clarification from Arne Redlich

Mike Ko <Michael@huaweisymantec.com> Thu, 20 August 2009 22:53 UTC

Return-Path: <Michael@huaweisymantec.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEF93A6DA1 for <storm@core3.amsl.com>; Thu, 20 Aug 2009 15:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.546
X-Spam-Level:
X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 KO81M4y8XEnA for <storm@core3.amsl.com>; Thu, 20 Aug 2009 15:53:24 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 2C77A3A6AE4 for <storm@ietf.org>; Thu, 20 Aug 2009 15:53:24 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_hI0kq9FRWpOTpBHvp1PBIw)"
Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KOP00C5Q68UE630@hstga02-in.huaweisymantec.com> for storm@ietf.org; Fri, 21 Aug 2009 06:53:19 +0800 (CST)
Received: from LENOVO6EA8F9DF ([68.65.79.146]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KOP00CI568SDI00@hstml02-in.huaweisymantec.com> for storm@ietf.org; Fri, 21 Aug 2009 06:53:18 +0800 (CST)
Message-id: <BD70C381B2D54578880018B5CB1C3151@china.huawei.com>
From: Mike Ko <Michael@huaweisymantec.com>
To: STORM <storm@ietf.org>
Date: Thu, 20 Aug 2009 15:53:46 -0700
X-Priority: 3
X-MSMail-priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: [storm] iSER clarification from Arne Redlich
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 22:53:25 -0000

In response to the question from Arne Redlich:

>From the perspective of the iSCSI layer, it is sending one large SCSI Data-in PDU to the initiator.  The iSER layer is responsible for packetizing the data into RDMA Write messages.  Hence the DataSegmentLength should be the full Data-in length.

Mike

-----  from Arne Redlich sent on June 22, 2009 to the IPS mailing list  -----

I'm unclear on the granularity with which an iSER target is supposed to
transfer Data-In via RDMA writes. Here's the pieces of information I'm
trying to tie together:

(1) The iSER spec replaces the initiator's MaxRecvDataSegmentLength with
InitiatorMaxRecvDSL, but this only applies to control type PDUs
(2) MaxBurstLength limits the size of Data-{In,Out} sequences, however,
the iSER spec is silent about Data-In sequences.
(3) RFC 5046, 7.3.5 (SCSI Data-In):
 "2. It MUST generate and send an RDMA Write Message containing the read
data to the initiator [...]
  c. It MUST use DataSegmentLength from the SCSI Data-in PDU to
determine the amount of data to be sent in the RDMA Write Message."

What is the iSCSI layer at the target supposed to use as
DataSegmentLength? MaxBurstLength? The full Data-In length?