Re: [storm] Send vs. Immediate

Elena Gurevich <elena.gurevich@toganetworks.com> Mon, 07 September 2015 09:49 UTC

Return-Path: <elena.gurevich@toganetworks.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8001B3E3B for <storm@ietfa.amsl.com>; Mon, 7 Sep 2015 02:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X44eoOUZiUKv for <storm@ietfa.amsl.com>; Mon, 7 Sep 2015 02:48:58 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0660.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::660]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CD61ACE9C for <storm@ietf.org>; Mon, 7 Sep 2015 02:48:58 -0700 (PDT)
Received: from HE1PR02MB0652.eurprd02.prod.outlook.com (10.161.118.12) by HE1PR02MB0652.eurprd02.prod.outlook.com (10.161.118.12) with Microsoft SMTP Server (TLS) id 15.1.262.15; Mon, 7 Sep 2015 09:48:39 +0000
Received: from HE1PR02MB0652.eurprd02.prod.outlook.com ([10.161.118.12]) by HE1PR02MB0652.eurprd02.prod.outlook.com ([10.161.118.12]) with mapi id 15.01.0262.011; Mon, 7 Sep 2015 09:48:39 +0000
From: Elena Gurevich <elena.gurevich@toganetworks.com>
To: Tom Talpey <tom@talpey.com>, "storm@ietf.org" <storm@ietf.org>
Thread-Topic: [storm] Send vs. Immediate
Thread-Index: AdDoie0+xkvsjYh7T92FPZdqNGMGkAAHrK+AACkxPhA=
Date: Mon, 07 Sep 2015 09:48:38 +0000
Message-ID: <HE1PR02MB0652931E7D44755A7F27CC95F9540@HE1PR02MB0652.eurprd02.prod.outlook.com>
References: <HE1PR02MB0652B5507B4434A631F6C70CF9550@HE1PR02MB0652.eurprd02.prod.outlook.com> <55EC40AD.4080005@talpey.com>
In-Reply-To: <55EC40AD.4080005@talpey.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=elena.gurevich@toganetworks.com;
x-originating-ip: [84.94.204.35]
x-microsoft-exchange-diagnostics: 1; HE1PR02MB0652; 5:s0Pi/mVvNKRaOwB4cM4Iy/AA39FWoaXOPPcaS7u7yY7WinIucDMiGzG3UtMDyXJTPZlq4ItPtz0MCxgZp0EGc+W8jF4aOuJAxXP9llyjD5YHF7wI4FVwgEL8uFOJFWZbQ28IpubIUjiaCnNapNHN3w==; 24:PMfMX+LXH4kdChzWTxepuJQLwXC3EqGkC3xFBI/dfJH4wt56ouSWyTMnz+WA/iAU4eYy7YZXDWZCU6aAhBy4aD2ycAmWW0M8R1SMUmaUA8k=; 20:D9ryYZpduKHeItbehawm+ukkQwaz00JU8hxzlepILPYsPaX46//Euv8W9A70pCC7CAcB9mPcU8iQFGRhRJBKqA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR02MB0652;
x-microsoft-antispam-prvs: <HE1PR02MB0652E6A95F93DA4B09EB72F8F9540@HE1PR02MB0652.eurprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:HE1PR02MB0652; BCL:0; PCL:0; RULEID:; SRVR:HE1PR02MB0652;
x-forefront-prvs: 069255B8B8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(13464003)(34854003)(479174004)(42154003)(377454003)(24454002)(5004730100002)(81156007)(106356001)(19580405001)(86362001)(2900100001)(5001860100001)(5007970100001)(50986999)(40100003)(102836002)(15975445007)(87936001)(5001830100001)(4001540100001)(105586002)(62966003)(2501003)(122556002)(5003600100002)(2950100001)(97736004)(33656002)(19580395003)(77096005)(76176999)(77156002)(66066001)(5002640100001)(64706001)(74316001)(5001770100001)(101416001)(10400500002)(5890100001)(107886002)(189998001)(68736005)(76576001)(92566002)(54356999)(46102003)(5001960100002)(14773001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR02MB0652; H:HE1PR02MB0652.eurprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: toganetworks.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: toganetworks.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2015 09:48:38.8687 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 73f7e7df-ca98-4f08-bf85-f137b447da96
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR02MB0652
Archived-At: <http://mailarchive.ietf.org/arch/msg/storm/wy4T6NS1BSdNRc58R75Buj4EnCc>
Subject: Re: [storm] Send vs. Immediate
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 07 Sep 2015 09:49:01 -0000

Hello Tom, thanks for a prompt response, my question was little bit different.

I failed to found differences in behavior between RDMA Write followed by Immediate Data and RDMA Write followed by Send.
Both consume untagged buffer of queue #0 - so at data sink this buffer should be preposted in both cases.

According to RFCs except DDP message format both operation has to be processed similarly as at data Source as at data Sink.

According to ordering and completion rules, specified in RFC 5040 and  7306:

First          |Second       | Placement         | Placement       | Ordering
Operation| Operation | Guarantee at     | Guarantee at   | Guarantee at
                 |                  | Remote Peer     | Local Peer        | Remote Peer
-------------+---------------+----------------------+--------------------+----------------
RDMA      | Send          | No placement   | Not applicable | Not applicable
Write       |                   | guarantee. If     |                         |
                |                   | guarantee is      |                         |
                |                   | necessary, see   |                         |
                |                   | footnote 1.         |                         |
-------------+---------------+----------------------+--------------------+------------------
RDMA     | Immediate| No Placement   | Not                   | Immediate Data
Write      | Data          | Guarantee         | Applicable        | is Completed
               |                   |                           |                          | after RDMA
               |                   |                           |                          | Write is Placed
               |                   |                           |                          | and Delivered

But even if the cell  "Ordering Guarantee at Remote Peer" is different for RDMA Write followed by Immediate Data and RDMA Write followed by Send.
At the end behavior has to be the same, because of specification of RFC5041 Section 5.4. ( see details in my original e-mail)

So why we need Immediate Data operation and cannot just reuse Send operation ?

Best regards,
Lena

-----Original Message-----
From: storm [mailto:storm-bounces@ietf.org] On Behalf Of Tom Talpey
Sent: Sunday, September 06, 2015 4:34 PM
To: storm@ietf.org
Subject: Re: [storm] Send vs. Immediate

On 9/6/2015 5:58 AM, Elena Gurevich wrote:
> Hello dear authors,
>
> I am new in iWARP and need your help to clear my  misunderstanding of RFCs.
>
> RFC5041 Section 5.4 stands that:
>
> "At the Data Sink, DDP MUST Deliver a DDP Message if and only if all
> of the following are true:
>
> * the last DDP Segment of the DDP Message had its Last flag set,
>
> * all of the DDP Segments of the DDP Message have been Placed,
>
> * all preceding DDP Messages have been Placed, and
>
> * each preceding DDP Message has been Delivered to the ULP."
>
> Let's assume that data sink receives sequence of "rdma_write" and send"
> messages.
>
> According to RFC even if miss ordering happens "send" can be delivered
> to RDMAP only after last segment of rdma_write arrives and is placed.
>
> So RDMAP layer completes "send" only after full rdma_write assembly.

These statements are correct, the Send is delivered only after Placing all the previous RDMA Write segments. This is a key behavior upon which most upper layers depend.

>
> If so why we need to generate new "Immediate request type" and cannot
> reuse 8 bytes length "send" ?

I don't understand the question. An Immediate is another behavior, and which is used by upper layers rather differently. Also, what
"8 bytes" are you referring to?

Perhaps you mean, why doesn't the upper layer use an RDMA Write with Immediate? Some upper layers do, I believe Lustre does, for example, but the original iWARP RDMAP (RFC5040) protocol did not support that operation. The RFC7306 extension, published last year, adds it.

Other upper layers, for example, iSER, NFS/RDMA, SMB Direct, etc, need a larger, separate message to complete an operation, and so use a full Send. These protocols use iWARP, without Immediates.

_______________________________________________
storm mailing list
storm@ietf.org
https://www.ietf.org/mailman/listinfo/storm
-------------------------------------------------------------------------------------------------------------------------------------------------
This email and any files transmitted and/or attachments with it are confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager. This message contains confidential
information of Toga Networks Ltd., and is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on
the contents of this information is strictly prohibited.
------------------------------------------------------------------------------------------------------------------------------------------------