Re: [storm] iSER update request from Alex Nezhinsky on AHS size

<Black_David@emc.com> Sat, 17 October 2009 00:47 UTC

Return-Path: <Black_David@emc.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 C9BAE3A68C0 for <storm@core3.amsl.com>; Fri, 16 Oct 2009 17:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level:
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 jOATRCiIjgrc for <storm@core3.amsl.com>; Fri, 16 Oct 2009 17:47:13 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D1A643A683E for <storm@ietf.org>; Fri, 16 Oct 2009 17:47:12 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n9H0kXtX027697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 20:46:33 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 16 Oct 2009 20:46:21 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n9H0kL2I015297; Fri, 16 Oct 2009 20:46:21 -0400
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 20:46:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4EC3.3ED95BCE"
Date: Fri, 16 Oct 2009 20:46:21 -0400
Message-ID: <9FA859626025B64FBC2AF149D97C944A040BF6DF@CORPUSMX80A.corp.emc.com>
In-Reply-To: <3156565070524C6D837F14783BA2FB60@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSER update request from Alex Nezhinsky on AHS size
Thread-Index: Acoh7cKM8jd8/d2mRdicSM4HYQcg2As1VRGA
References: <3156565070524C6D837F14783BA2FB60@china.huawei.com>
From: Black_David@emc.com
To: Michael@huaweisymantec.com, storm@ietf.org
X-OriginalArrivalTime: 17 Oct 2009 00:46:21.0387 (UTC) FILETIME=[3EDEF9B0:01CA4EC3]
X-EMM-EM: Active
Subject: Re: [storm] iSER update request from Alex Nezhinsky on AHS size
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: Sat, 17 Oct 2009 00:47:13 -0000

WG chair hat off:
 
That sounds like a reasonable solution.  What's the typical value
that IB implementations use?  That value will want to be the default
for this new key.

Thanks,
--David


 


________________________________

	From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
Behalf Of Mike Ko
	Sent: Thursday, August 20, 2009 7:26 PM
	To: STORM
	Subject: [storm] iSER update request from Alex Nezhinsky on AHS
size
	
	
	Alex sent me the following iSER update request:
	 
	> In the Infiniband implementation ISER has to post recv-buffers
for
	> the maximal possible message length. If a PDU contains AHS,
then no
	> upper size limit can be set beforehand, because AHS size is
not fixed
	> (it is determined by the contents of BHS, TotalAHSLength
field). Then
	> our posted buffer may prove insufficient.
	>
	> Suggested solution: to add a hard limit on AHS length as an
	> operational parameter, per session. This is in a sense similar
to
	> MaxOutstandingUnexpectedPDUs key which has no
	> meaning in a stream-based protocol.
	 
	It sounds reasonable to me.  If there is no objection, we can
add the MaxAHSLength key to the iSER update as Alex suggested.
	 
	Mike