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
>