Re: [rddp] [Ips] Storage Maintenance (storm) BOF reminder & requests
"Robert D. Russell" <rdr@iol.unh.edu> Tue, 24 March 2009 21:08 UTC
Return-Path: <rdr@iol.unh.edu>
X-Original-To: rddp@core3.amsl.com
Delivered-To: rddp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0033A28C316 for <rddp@core3.amsl.com>; Tue, 24 Mar 2009 14:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599]
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 WjPOy5X-Lq8v for <rddp@core3.amsl.com>; Tue, 24 Mar 2009 14:08:12 -0700 (PDT)
Received: from postal.iol.unh.edu (postal.iol.unh.edu [132.177.123.84]) by core3.amsl.com (Postfix) with ESMTP id 2AF0628C33A for <rddp@ietf.org>; Tue, 24 Mar 2009 14:07:52 -0700 (PDT)
Received: from postal.iol.unh.edu (localhost [127.0.0.1]) by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id n2OL8c2Z026293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2009 17:08:38 -0400
Received: from localhost (rdr@localhost) by postal.iol.unh.edu (8.14.0/8.14.0/Submit) with ESMTP id n2OL8buI026290; Tue, 24 Mar 2009 17:08:38 -0400
X-Authentication-Warning: postal.iol.unh.edu: rdr owned process doing -bs
Date: Tue, 24 Mar 2009 17:08:37 -0400
From: "Robert D. Russell" <rdr@iol.unh.edu>
To: Caitlin Bestler <cait@asomi.com>
In-Reply-To: <52130.1237926850@asomi.com>
Message-ID: <Pine.LNX.4.64.0903241702320.25436@postal.iol.unh.edu>
References: <52130.1237926850@asomi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Mailman-Approved-At: Wed, 25 Mar 2009 08:27:54 -0700
Cc: rddp@ietf.org
Subject: Re: [rddp] [Ips] Storage Maintenance (storm) BOF reminder & requests
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rddp>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 21:08:13 -0000
Ok, so this is a Linux problem, not an iWARP problem. Does this mean iSCSI/iSER currently runs with the transition on Windows? What are some other Operating Systems that also do it the "right" way? In any case, it might be useful to have a "Standard" way of bringing up initial connections in RDMA mode without the necessity to go through the negotiation. This may be faster, and in many situations it is already known that RDMA mode will be used, so the transition is just an extra, unnecessary step. If nothing else, having such a Standard would bring InfiniBand, and perhaps other technologies, into compliance -- as far as I know, InfiniBand cannot do the transition on any operating system. Please let me know if that is incorrect. Thanks, Bob Russell On Tue, 24 Mar 2009, Caitlin Bestler wrote: > > > > > > >> On Tue Mar 24 8:26 , Bernard Metzler <BMT@zurich.ibm.com> wrote: >> Hi Robert, >> >> an RNIC would be happy to transition an established >> socket into RDMA mode if the user wants to. No problem - >> as far as i know - to transition from TOE mode to RDMA mode at least. >> It is a question of envrionmental support to allow that. To allow that, >> the environment (aka OFED) wold have to integrate >> late socket translation, which allows RNIC drivers to officially >> do TOE to RDMA mode transition or to take over a socket >> >> (where the OS would have to expose a well-defined >> TCP context reallocation scheme). >> Maybe it is not a good idea to change an end-to-end >> protocol because a host environment has functional limitations >> which may stem from historical transport (IB) limitations >> or OS considerations. >> > > I agree with Bernard. > > Conventional RNICs are indeed transitioning streaming mode TCP connections > to MPA for iWARP in full compliance with the existing RFCs. > > What Linux has not implemented is transitioning a host-created streaming mode > TCP connection to an offload device held streaming mode TCP connection. > That is a very complex issue, which fortunately for this forum, is out of scope. > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www.ietf.org/mailman/listinfo/rddp >
- [rddp] Storage Maintenance (storm) BOF reminder &… Black_David
- [rddp] STORM BOF time Black_David
- Re: [rddp] Storage Maintenance (storm) BOF remind… Stephen Bailey
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Julian Satran
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Lars Eggert
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Knight, Frederick
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Mallikarjun C.
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Robert D. Russell
- Re: [rddp] [Junk released by Allow List] Re: [Ips… Felix Marti
- Re: [rddp] [Junk released by Allow List] Re: [Ips… Mikkel Hagen
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Bernard Metzler
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Caitlin Bestler
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Caitlin Bestler
- Re: [rddp] Storage Maintenance (storm) BOF remind… Uri Elzur
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Robert D. Russell
- Re: [rddp] Storage Maintenance (storm) BOF remind… Fredy Neeser
- Re: [rddp] Storage Maintenance (storm) BOF remind… Minturn, Dave B
- Re: [rddp] Storage Maintenance (storm) BOF remind… Felix Marti