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