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. ------------------------------------------------------------------------------------------------------------------------------------------------
- [storm] Send vs. Immediate Elena Gurevich
- Re: [storm] Send vs. Immediate Tom Talpey
- Re: [storm] Send vs. Immediate Elena Gurevich
- Re: [storm] Send vs. Immediate Tom Talpey
- Re: [storm] Send vs. Immediate Elena Gurevich
- Re: [storm] Send vs. Immediate Tom Talpey