[要約] RFC 7306は、RDMAプロトコルの拡張に関するものであり、RDMAの機能を向上させるための仕様を提供しています。目的は、高速で効率的なデータ転送を実現し、ネットワークのパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) H. Shah
Request for Comments: 7306 Broadcom Corporation
Category: Standards Track F. Marti
ISSN: 2070-1721 W. Noureddine
A. Eiriksson
Chelsio Communications, Inc.
R. Sharp
Intel Corporation
June 2014
Remote Direct Memory Access (RDMA) Protocol Extensions
リモートダイレクトメモリアクセス（RDMA）プロトコル拡張
Abstract
概要
This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040. RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.
このドキュメントでは、RFC 5040で指定されているIETFリモートダイレクトメモリアクセスプロトコル（RDMAP）の拡張について説明します。RDMAPは、アプリケーションに直接読み取りおよび書き込みサービスを提供し、中間データコピーなしでデータを直接上位プロトコル（ULP）バッファーに転送できるようにします。 。このドキュメントで指定されている拡張機能は、次の機能や改善を提供します：アトミック操作と即時データ。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7306.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7306で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Discovery of RDMAP Extensions ..............................5
2. Requirements Language ...........................................5
3. Glossary ........................................................6
4. Header Format Extensions ........................................7
4.1. RDMAP Control and Invalidate STag Fields ...................7
4.2. RDMA Message Definitions ...................................9
5. Atomic Operations ...............................................9
5.1. Atomic Operation Details ..................................10
5.1.1. FetchAdd ...........................................10
5.1.2. CmpSwap ............................................12
5.2. Atomic Operations .........................................13
5.2.1. Atomic Operation Request Message ...................14
5.2.2. Atomic Operation Response Message ..................17
5.3. Atomicity Guarantees ......................................18
5.4. Atomic Operations Ordering and Completion Rules ...........18
6. Immediate Data .................................................20
6.1. RDMAP Interactions with ULP for Immediate Data ............20
6.2. Immediate Data Header Format ..............................21
6.3. Immediate Data or Immediate Data with SE Message ..........21
6.4. Ordering and Completions ..................................22
7. Ordering and Completions Table .................................22
8. Error Processing ...............................................25
8.1. Errors Detected at the Local Peer .........................25
8.2. Errors Detected at the Remote Peer ........................26
9. Security Considerations ........................................26
10. IANA Considerations ...........................................27
10.1. RDMAP Message Atomic Operation Subcodes ..................27
10.2. RDMAP Queue Numbers ......................................28
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................29
12. Acknowledgments ...............................................30
Appendix A. DDP Segment Formats for RDMA Messages .................31
A.1. DDP Segment for Atomic Operation Request ..................32
A.2. DDP Segment for Atomic Response ...........................33
A.3. DDP Segment for Immediate Data and Immediate Data with SE .33
The RDMA Protocol [RFC5040] provides capabilities for zero-copy data communications that preserve memory protection semantics, enabling more efficient network protocol implementations. The RDMA Protocol is part of the iWARP family of specifications which also include RFC 5041 [RFC5041], RFC 5044 [RFC5044], and RFC 6581 [RFC6581]. This document specifies the following extensions to the RDMA Protocol (RDMAP):
RDMAプロトコル[RFC5040]は、メモリ保護のセマンティクスを維持するゼロコピーデータ通信の機能を提供し、より効率的なネットワークプロトコルの実装を可能にします。 RDMAプロトコルは、RFC 5041 [RFC5041]、RFC 5044 [RFC5044]、およびRFC 6581 [RFC6581]を含むiWARPファミリーの仕様の一部です。このドキュメントでは、RDMAプロトコル（RDMAP）に対する次の拡張を指定しています。
o Atomic Operations can be performed on remote memory locations. Support for Atomic Operations enhances the usability of RDMAP in distributed shared-memory environments.
o アトミック操作は、リモートメモリロケーションで実行できます。 Atomic Operationsのサポートにより、分散共有メモリ環境でのRDMAPの使いやすさが向上します。
o Immediate Data messages allow the ULP at the sender to provide a small amount of data. When an Immediate Data message is sent following an RDMA Write Message, the combination of the two messages is an implementation of RDMA Write with Immediate message that is found in other RDMA transport protocols.
o 即時データメッセージを使用すると、送信側のULPが少量のデータを提供できます。即時データメッセージがRDMA書き込みメッセージの後に送信される場合、2つのメッセージの組み合わせは、他のRDMAトランスポートプロトコルで見られるRDMA書き込みと即時メッセージの実装です。
Other RDMA transport protocols define the functionality added by these extensions leading to differences in RDMA applications and/or Upper-Layer Protocols. Removing these differences in the transport protocols simplifies these applications and ULPs, and that is the main motivation for the extensions specified in this document.
その他のRDMAトランスポートプロトコルは、これらの拡張機能によって追加された機能を定義し、RDMAアプリケーションや上位層プロトコルの違いにつながります。トランスポートプロトコルのこれらの違いを取り除くことで、これらのアプリケーションとULPが簡素化されます。これが、このドキュメントで指定されている拡張機能の主な動機です。
RSockets [RSOCKETS] is an example of RDMA-enabled middleware that provides a socket interface as the upper-edge interface and utilizes RDMA to provide more efficient networking for socket-based applications. RSockets is aware of Immediate Data support in InfiniBand [IB]. RSockets cannot utilize the RDMA Write with Immediate Data operation from InfiniBand. The addition of the Immediate Data operation specified in this document will alleviate this difference in RSockets when running on InfiniBand and iWARP.
RSockets [RSOCKETS]は、RDMA対応ミドルウェアの例であり、アッパーエッジインターフェースとしてソケットインターフェースを提供し、RDMAを利用して、ソケットベースのアプリケーションにより効率的なネットワークを提供します。 RSocketsは、InfiniBand [IB]での即時データサポートを認識しています。 RSocketsは、InfiniBandからのRDMA Write with Immediate Data操作を利用できません。このドキュメントで指定されている即時データ操作を追加すると、InfiniBandとiWARPで実行する場合のRSocketsのこの違いが緩和されます。
Structured high-performance computing applications based on the Message-Passing Interface [MPI] may use Atomic Operations defined in this specification. DAT Atomics [DAT_ATOMICS] is an example of RDMA-enabled middleware that provides a portable RDMA programming interface for various RDMA transport protocols. DAT Atomics includes a primitive for InfiniBand that is not supported by iWARP RDMA-enabled Network Interface Controllers or RNICs. The addition of Atomic Operations as specified in this document will allow Atomic Operations in DAT Atomics to work for both InfiniBand and RNICs interchangeably.
Message-Passing Interface [MPI]に基づく構造化された高性能コンピューティングアプリケーションは、この仕様で定義されているAtomic Operationsを使用できます。 DAT Atomics [DAT_ATOMICS]は、さまざまなRDMAトランスポートプロトコルにポータブルRDMAプログラミングインターフェイスを提供するRDMA対応ミドルウェアの例です。 DAT Atomicsには、iWARP RDMA対応のネットワークインターフェースコントローラーまたはRNICでサポートされていないInfiniBandのプリミティブが含まれています。このドキュメントで指定されているようにアトミック操作を追加すると、DATアトミックのアトミック操作がInfiniBandとRNICの両方で互換的に機能するようになります。
For more background on RDMA Protocol applicability, see "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement Protocol (DDP)" [RFC5045].
RDMAプロトコルの適用性の詳細については、「リモートダイレクトメモリアクセスプロトコル（RDMA）および直接データ配置プロトコル（DDP）の適用性」[RFC5045]を参照してください。
Today there are RDMA applications and/or ULPs that are aware of the existence of Atomic and Immediate Data operations for RDMA transports such as InfiniBand and application programming interfaces such as Open Fabrics Verbs [OFAVERBS]. Today, these applications need to be aware that RDMAP does not support certain of these operations. Typically, the availability of these capabilities is exposed to the applications through adapter query interfaces in software. Applications then have to decide to use or not use Immediate Data or Atomic Operations based on the results of the query interfaces. Such query interfaces typically return the scope of atomicity guarantees, not the individual Atomic Operations supported. Therefore, this specification requires all Atomic Operations defined within to be supported if an RNIC supports any Atomic Operations.
今日、RDMAアプリケーションやULPがあり、InfiniBandなどのRDMAトランスポートおよびOpen Fabrics Verbs [OFAVERBS]などのアプリケーションプログラミングインターフェイスのアトミックおよび即時データ操作の存在を認識しています。現在、これらのアプリケーションは、RDMAPがこれらの操作の一部をサポートしていないことを認識する必要があります。通常、これらの機能の可用性は、ソフトウェアのアダプタークエリインターフェイスを通じてアプリケーションに公開されます。次に、アプリケーションは、クエリインターフェイスの結果に基づいて、即時データまたはアトミック操作を使用するか使用しないかを決定する必要があります。このようなクエリインターフェイスは、通常、サポートされる個々の原子操作ではなく、原子性保証の範囲を返します。したがって、この仕様では、RNICがアトミック操作をサポートしている場合、その中で定義されているすべてのアトミック操作がサポートされている必要があります。
In cases where heterogeneous hardware, with differing support for Atomic Operations and Immediate Data Operations, is deployed for use by RDMA applications and/or ULPs, applications are either statically configured to use or not use optional features or use application-specific negotiation mechanisms. For the extensions covered by this document, it is RECOMMENDED that RDMA applications and/or ULPs negotiate at the application or ULP level the usage of these extensions. The definition of such application-specific mechanisms is outside the scope of this specification. For backward compatibility, existing applications and/or ULPs should not assume that these extensions are supported.
アトミック操作と即時データ操作のサポートが異なる異種ハードウェアがRDMAアプリケーションやULPで使用するために展開される場合、アプリケーションは、オプション機能を使用するか使用しないか、またはアプリケーション固有のネゴシエーションメカニズムを使用するように静的に構成されます。このドキュメントの対象となる拡張機能については、RDMAアプリケーションやULPがアプリケーションまたはULPレベルでこれらの拡張機能の使用についてネゴシエートすることをお勧めします。このようなアプリケーション固有のメカニズムの定義は、この仕様の範囲外です。下位互換性のために、既存のアプリケーションやULPは、これらの拡張機能がサポートされていると想定しないでください。
In the absence of application-specific negotiation of the features defined within this specification, the new operations can be attempted, and reported errors can be used to determine a remote peer's capabilities. In the case of Atomics, a FetchAdd operation with "Add Data" set to 0 can safely be used to determine the existence of Atomic Operations without modifying the content of a remote peer's memory. A Remote Operation Error or Unexpected OpCode error will be reported by the remote peer if there is an Immediate Data or Atomic Operation that is not supported by the remote peer.
この仕様で定義されている機能のアプリケーション固有のネゴシエーションがない場合、新しい操作を試行でき、報告されたエラーを使用してリモートピアの機能を判断できます。 Atomicsの場合、 "Add Data"を0に設定したFetchAdd操作を安全に使用して、リモートピアのメモリの内容を変更せずにAtomic Operationsの存在を判断できます。リモートピアでサポートされていない即時データまたはアトミック操作が存在する場合、リモートオペレーションエラーまたは予期しないOpCodeエラーがリモートピアによって報告されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document is an extension of RFC 5040, and key words are defined in the glossary of that document.
このドキュメントはRFC 5040の拡張であり、キーワードはそのドキュメントの用語集で定義されています。
Atomic Operation - an operation that results in an execution of a memory operation at a specific ULP Buffer address on a remote node using the Tagged Buffer data transfer model. The consumer can use Atomic Operations to read, modify, and write memory at the destination ULP Buffer address, while at the same time guaranteeing that no other Atomic Operation read or write accesses to the ULP Buffer address targeted by the Atomic Operation will occur across any other RDMAP Streams on an RNIC at the Responder.
アトミック操作-タグ付きバッファデータ転送モデルを使用して、リモートノードの特定のULPバッファアドレスでメモリ操作を実行する操作。アトミック操作を使用して、宛先のULPバッファーアドレスでメモリの読み取り、変更、書き込みを行うことができます。同時に、アトミック操作の対象となるULPバッファーアドレスへの他のアトミック操作の読み取りまたは書き込みアクセスが発生しないレスポンダのRNIC上の他のRDMAPストリーム。
Atomic Operation Request - an RDMA Message used by the Data Source to perform an Atomic Operation at the Responder.
アトミック操作要求-レスポンダでアトミック操作を実行するためにデータソースによって使用されるRDMAメッセージ。
Atomic Operation Response - an RDMA Message used by the Responder to describe the completion of an Atomic Operation at the Responder.
アトミック操作応答-レスポンダでアトミック操作の完了を説明するためにレスポンダが使用するRDMAメッセージ。
CmpSwap - an Atomic Operation that is used to compare and swap a value at a specific address on a remote node.
CmpSwap-リモートノードの特定のアドレスで値を比較および交換するために使用されるアトミック操作。
FetchAdd - an Atomic Operation that is used to atomically increment a value at a specific ULP Buffer address on a remote node.
FetchAdd-リモートノードの特定のULPバッファーアドレスで値をアトミックにインクリメントするために使用されるアトミック操作。
Immediate Data - a small fixed-size portion of data sent from the Data Source to a Data Sink.
即時データ-データソースからデータシンクに送信されるデータの固定サイズの小さな部分。
Immediate Data Message - an RDMA Message used by the Data Source to send Immediate Data to the Data Sink.
即時データメッセージ-即時データをデータシンクに送信するためにデータソースが使用するRDMAメッセージ。
Immediate Data with Solicited Event (SE) Message - an RDMA Message used by the Data Source to send Immediate Data with Solicited Event to the Data Sink.
要請イベント付き即時データ（SE）メッセージ-要請イベント付き即時データをデータシンクに送信するためにデータソースが使用するRDMAメッセージ。
iWARP - a suite of wire protocols comprised of RFC 5040, RFC 5041, RFC 5044, and RFC 6581.
iWARP-RFC 5040、RFC 5041、RFC 5044、およびRFC 6581で構成されるワイヤプロトコルのスイート。
Requester - the sender of an RDMA Atomic Operation request.
リクエスタ-RDMA Atomic Operationリクエストの送信者。
Responder - the receiver of an RDMA Atomic Operation request.
Responder-RDMA Atomic Operationリクエストの受信者。
RNIC - RDMA-enabled Network Interface Controller. In this context, this would be a network I/O adapter or embedded controller with iWARP functionality.
RNIC-RDMA対応のネットワークインターフェイスコントローラー。このコンテキストでは、これはiWARP機能を備えたネットワークI / Oアダプターまたは組み込みコントローラーです。
ULP - Upper-Layer Protocol. The protocol layer above the one currently being referenced. The ULP for RFC 5040 / RFC 5041 is expected to be an OS, Application, adaptation layer, or proprietary device. The RFC 5040 / RFC 5041 documents do not specify a ULP -- they provide a set of semantics that allow a ULP to be designed to utilize RFC 5040 / RFC 5041.
ULP-上位層プロトコル。現在参照されているものより上のプロトコル層。 RFC 5040 / RFC 5041のULPは、OS、アプリケーション、アダプテーション層、または独自のデバイスであることが期待されています。 RFC 5040 / RFC 5041ドキュメントはULPを指定していません。これらのドキュメントは、ULPがRFC 5040 / RFC 5041を利用するように設計できるようにする一連のセマンティクスを提供します。
The control information of RDMA Messages is included in header fields defined in RFC 5041, the Direct Data Placement (DDP) protocol. RFC 5040 defines the RDMAP header formats layered on the DDP header definition. This specification extends RFC 5040 with the following new formats:
RDMAメッセージの制御情報は、RFC 5041、Direct Data Placement（DDP）プロトコルで定義されたヘッダーフィールドに含まれています。 RFC 5040は、DDPヘッダー定義に階層化されたRDMAPヘッダー形式を定義しています。この仕様は、次の新しい形式でRFC 5040を拡張します。
o Four new RDMA Messages carry additional RDMAP headers. The Immediate Data operation and Immediate Data with Solicited Event operation each include 8 bytes of data following the RDMAP header. Atomic Operations include Atomic Request or Atomic Response headers following the RDMAP header. The RDMAP header for Atomic Request messages is 52 bytes long as specified in Figure 4. The RDMAP header for Atomic Response Messages is 32 bytes long as specified in Figure 5.
o 4つの新しいRDMAメッセージには、追加のRDMAPヘッダーが含まれています。即時データ操作および要請イベント操作の即時データ操作には、それぞれRDMAPヘッダーに続く8バイトのデータが含まれます。 Atomic Operationsには、RDMAPヘッダーに続くAtomic RequestまたはAtomic Responseヘッダーが含まれます。 Atomic RequestメッセージのRDMAPヘッダーは、図4で指定されているように52バイト長です。AtomicResponseメッセージのRDMAPヘッダーは、図5で指定されているように32バイト長です。
o Introduction of a new queue for untagged Buffers (QN=3) used for Atomic Response tracking.
o Atomic Responseトラッキングに使用されるタグなしバッファ（QN = 3）の新しいキューの導入。
For reference, Figure 1 depicts the format of the DDP Control and RDMAP Control Fields, in the style and convention of RFC 5040:
参考までに、図1は、RFC 5040の形式と規則で、DDP制御フィールドとRDMAP制御フィールドのフォーマットを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Resrv | DV| RV|Rsv| Opcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DDP Control and RDMAP Control Fields
図1：DDP制御およびRDMAP制御フィールド
The DDP Control Field consists of the T (Tagged), L (Last), Resrv, and DV (DDP protocol Version) fields [RFC5041]. The RDMAP Control Field consists of the RV (RDMA Version), Rsv, and Opcode fields [RFC5040].
DDP制御フィールドは、T（タグ付き）、L（最終）、Resrv、およびDV（DDPプロトコルバージョン）フィールドで構成されます[RFC5041]。 RDMAPコントロールフィールドは、RV（RDMAバージョン）、Rsv、およびOpcodeフィールドで構成されます[RFC5040]。
This specification adds values for the RDMA Opcode field to those specified in RFC 5040. Figure 2 defines the new values of the RDMA Opcode field that are used for the RDMA Messages defined in this specification.
この仕様は、RDMA Opcodeフィールドの値をRFC 5040で指定された値に追加します。図2は、この仕様で定義されたRDMAメッセージに使用されるRDMA Opcodeフィールドの新しい値を定義します。
As shown in Figure 2, STag (Steering Tag) and Tagged Offset are not applicable for the RDMA Messages defined in this specification. Figure 2 also shows the appropriate Queue Number for each Opcode.
図2に示すように、STag（ステアリングタグ）およびタグ付きオフセットは、この仕様で定義されているRDMAメッセージには適用されません。図2は、各オペコードの適切なキュー番号も示しています。
All RDMA Messages defined in this specification MUST have:
この仕様で定義されているすべてのRDMAメッセージには、以下が必要です。
The RDMA Version (RV) field: 01b.
RDMAバージョン（RV）フィールド：01b。
Opcode field: Set to one of the values in Figure 2.
Opcodeフィールド：図2のいずれかの値に設定します。
Invalidate STag: Set to zero by the sender, ignored by the receiver.
STagを無効化：送信者がゼロに設定し、受信者は無視します。
-------+-----------+-------+------+-------+---------+-------------
RDMA | Message | Tagged| STag | Queue | In- | Message
Opcode | Type | Flag | and | Number| validate| Length
| | | TO | | STag | Communicated
| | | | | | between DDP
| | | | | | and RDMAP
-------+-----------+-------+------+-------+---------+-------------
1000b | Immediate | 0 | N/A | 0 | N/A | Yes
| Data | | | | |
-------+-----------+----------------------------------------------
1001b | Immediate | 0 | N/A | 0 | N/A | Yes
| Data with | | | | |
| SE | | | | |
-------+-----------+----------------------------------------------
1010b | Atomic | 0 | N/A | 1 | N/A | Yes
| Request | | | | |
-------+-----------+----------------------------------------------
1011b | Atomic | 0 | N/A | 3 | N/A | Yes
| Response | | | | |
-------+-----------+----------------------------------------------
Figure 2: Additional RDMA Usage of DDP Fields
図2：DDPフィールドの追加のRDMA使用
Note: N/A means Not Applicable.
注：N / Aは該当なしを意味します。
This extension defines RDMAP use of Queue Number 3 for Untagged Buffers for Atomic Responses. This queue is used for tracking outstanding Atomic Requests.
この拡張機能は、アトミック応答のタグなしバッファーに対するキュー番号3のRDMAP使用を定義します。このキューは、未解決のアトミックリクエストを追跡するために使用されます。
All other DDP and RDMAP Control Fields are set as described in RFC 5040.
他のすべてのDDPおよびRDMAP制御フィールドは、RFC 5040で説明されているように設定されます。
The following figure defines which RDMA Headers are used on each new RDMA Message and which new RDMA Messages are allowed to carry ULP payload.
次の図は、新しい各RDMAメッセージで使用されるRDMAヘッダーと、ULPペイロードの伝送を許可される新しいRDMAメッセージを定義しています。
-------+-----------+-------------------+-------------------------
RDMA | Message | RDMA Header Used | ULP Message allowed in
Message| Type | | the RDMA Message
OpCode | | |
| | |
-------+-----------+-------------------+-------------------------
1000b | Immediate | Immediate Data | No
| Data | Header |
-------+-----------+-------------------+-------------------------
1001b | Immediate | Immediate Data | No
| Data with | Header |
| SE | |
-------+-----------+-------------------+-------------------------
1010b | Atomic | Atomic Request | No
| Request | Header |
-------+-----------+-------------------+-------------------------
1011b | Atomic | Atomic Response | No
| Response | Header |
-------+-----------+-------------------+-------------------------
Figure 3: RDMA Message Definitions
図3：RDMAメッセージの定義
The RDMA Protocol Specification in RFC 5040 does not include support for Atomic Operations, which are an important building block for implementing distributed shared memory.
RFC 5040のRDMAプロトコル仕様には、分散共有メモリを実装するための重要なビルディングブロックであるアトミック操作のサポートが含まれていません。
This document extends the RDMA Protocol specification with a set of basic Atomic Operations and specifies their resource and ordering rules. The Atomic Operations specified in this document provide equivalent functionality to the InfiniBand RDMA transport as well as extended Atomic Operations defined in Open Fabrics Verbs, to allow applications that use these primitives to work interchangeably over iWARP. Other operations are left for future consideration.
このドキュメントは、基本的なアトミック操作のセットでRDMAプロトコル仕様を拡張し、それらのリソースと順序ルールを指定します。このドキュメントで指定されているアトミックオペレーションは、InfiniBand RDMAトランスポートと同等の機能を提供するほか、Open Fabrics動詞で定義された拡張アトミックオペレーションを提供して、これらのプリミティブを使用するアプリケーションがiWARPを介して互換的に動作できるようにします。その他の操作は、将来の検討のために残されています。
Atomic Operations as specified in this document execute a 64-bit memory operation at a specified destination ULP Buffer address on a Responder node using the Tagged Buffer data transfer model. The operations atomically read, modify, and write back the contents of the destination ULP Buffer address and guarantee that Atomic Operations on this ULP Buffer address by other RDMAP Streams on the same RNIC do not occur between the read and the write caused by the Atomic Operation. Therefore, the Responder RNIC MUST implement mechanisms to prevent Atomic Operations to a memory registered for Atomic Operations while an Atomic Operation targeting the memory is in progress. The Requester of an Atomic Operation cannot rely on Atomic Operation behavior at the Responder across multiple RNICs or with respect to other applications/ULPs running at the Responder that can access the ULP Buffer. It is OPTIONAL for an RNIC to provide such behavior when implementing the Atomic Operations specified in this document. An RNIC that supports Atomic Operations as specified in this document MUST implement both the FetchAdd operation as specified in Section 5.1.1 and the CmpSwap operation as specified in Section 5.1.2. The advertisement of Tagged Buffer information for Atomic Operations is outside the scope of this specification and is handled by the ULPs.
このドキュメントで指定されているアトミック操作は、タグ付きバッファデータ転送モデルを使用して、レスポンダノードの指定された宛先ULPバッファアドレスで64ビットメモリ操作を実行します。操作は、宛先ULPバッファーアドレスの内容をアトミックに読み取り、変更、および書き戻し、同じRNIC上の他のRDMAPストリームによるこのULPバッファーアドレスのアトミック操作が、アトミック操作による読み取りと書き込みの間に発生しないことを保証します。 。したがって、Responder RNICは、メモリを対象とするアトミック操作の進行中に、アトミック操作に登録されたメモリへのアトミック操作を防ぐメカニズムを実装する必要があります。アトミック操作のリクエスターは、複数のRNIC間、またはULPバッファーにアクセスできるレスポンダーで実行されている他のアプリケーション/ ULPに関して、レスポンダーでのアトミック操作の動作に依存できません。このドキュメントで指定されているアトミック操作を実装するときに、RNICがそのような動作を提供することはオプションです。このドキュメントで指定されているアトミック操作をサポートするRNICは、セクション5.1.1で指定されているFetchAdd操作と、セクション5.1.2で指定されているCmpSwap操作の両方を実装する必要があります。 Atomic Operationsのタグ付きバッファ情報のアドバタイズは、この仕様の範囲外であり、ULPによって処理されます。
Implementation note: It is RECOMMENDED that the applications do not use the ULP Buffer addresses used for Atomic Operations for other RDMA operations due to the lack of atomicity guarantees between operations other than Atomic Operations.
実装上の注意：アトミック操作以外の操作間に原子性の保証がないため、他のRDMA操作ではアトミック操作に使用されるULPバッファーアドレスをアプリケーションで使用しないことをお勧めします。
Implementation note: Errors related to the alignment in the following sections cover Atomic Operations targeted at a ULP Buffer address that is not aligned to a 64-bit boundary.
実装上の注意：次のセクションのアライメントに関連するエラーは、64ビット境界にアライメントされていないULPバッファーアドレスを対象とするアトミック操作をカバーしています。
Atomic Operation Request Messages use the same remote addressing mechanism as RDMA Reads and Writes. The ULP Buffer address specified in the request is in the address space of the Remote Peer to which the Atomic Operation is targeted.
アトミック操作要求メッセージは、RDMA読み取りおよび書き込みと同じリモートアドレス指定メカニズムを使用します。要求で指定されたULPバッファーアドレスは、アトミック操作の対象となるリモートピアのアドレススペースにあります。
Atomic Operation Response Messages MUST use the Untagged Buffer model with QN=3. Queue number 3 will be used to track outstanding Atomic Operation Request messages at the Requester. When the Atomic Operation Response message is received, the Message Sequence Number (MSN) will be used to locate the corresponding Atomic Operation request in order to complete the Atomic Operation request.
アトミック操作応答メッセージは、QN = 3のタグなしバッファーモデルを使用する必要があります。キュー番号3は、リクエスターで未解決のアトミック操作要求メッセージを追跡するために使用されます。アトミック操作応答メッセージが受信されると、アトミック操作要求を完了するために、対応するアトミック操作要求を見つけるためにメッセージシーケンス番号（MSN）が使用されます。
The following subsections describe the Atomic Operations in more detail.
次のサブセクションでは、原子操作について詳しく説明します。
The FetchAdd Atomic Operation requests the Responder to read a 64-bit Original Remote Data Value at a 64-bit aligned ULP Buffer address in the Responder's memory, perform the FetchAdd operation on multiple fields of selectable length specified by 64-bit "Add Mask", and write the result back to the same ULP Buffer address. The Atomic addition is performed independently on each one of these fields. A bit set in the Add Mask field specifies the field boundary; for each field, a bit is set at the most significant bit position for each field, causing any carry out of that bit position to be discarded when the addition is performed.
FetchAddアトミック操作は、レスポンダーのメモリ内の64ビットで整列されたULPバッファーアドレスで64ビットの元のリモートデータ値を読み取るようにレスポンダーに要求し、64ビットの「マスクの追加」で指定された選択可能な長さの複数のフィールドでFetchAdd操作を実行します、結果を同じULPバッファアドレスに書き戻します。原子の追加は、これらのフィールドのそれぞれで独立して実行されます。 Add Maskフィールドで設定されたビットは、フィールド境界を指定します。フィールドごとに、各フィールドの最上位ビット位置にビットが設定され、加算が実行されるときにそのビット位置からの桁上げが破棄されます。
FetchAdd Atomic Operations MUST target ULP Buffer addresses that are 64-bit aligned. FetchAdd Atomic Operations that target ULP Buffer addresses that are not 64-bit aligned MUST be surfaced as errors, and the Responder's memory MUST NOT be modified in such cases. Additionally, an error MUST be surfaced and a terminate message MUST be generated. The setting of the Add Mask field to 0x0000000000000000 results in Atomic Add of 64-bit Original Remote Data Value and 64-bit "Add Data".
FetchAddアトミック操作は、64ビットにアラインされたULPバッファーアドレスをターゲットにする必要があります。 64ビットに整列されていないULPバッファーアドレスをターゲットとするFetchAddアトミック操作は、エラーとして表面化されなければならず（MUST）、そのような場合、レスポンダのメモリを変更してはなりません（MUST NOT）。さらに、エラーが表面化しなければならず、終了メッセージが生成されなければなりません。 Add Maskフィールドを0x0000000000000000に設定すると、64ビットの元のリモートデータ値と64ビットの「データの追加」のアトミックな追加が行われます。
The pseudocode below describes a masked FetchAdd Atomic Operation.
以下の擬似コードは、マスクされたFetchAddアトミック操作を記述しています。
bit_location = 1
carry = 0
Remote Data Value = 0
リモートデータ値= 0
for bit = 0 to 63
ビット= 0から63
{
｛
if (bit != 0 ) bit_location = bit_location << 1
val1 = (Original Remote Data Value & bit_location) >> bit
val2 = (Add Data & bit_location) >> bit
sum = carry + val1 + val2
carry = (sum & 2) >> 1
sum = sum & 1
私と私= 1
if (sum)
もし（合計）
Remote Data Value |= bit_location
リモートデータ値| = bit_location
carry = ((carry) && (!(Add Mask & bit_location)))
} The FetchAdd operation is performed in the endian format of the target memory. The "Original Remote Data Value" is converted from the endian format of the target memory for return and returned to the Requester. The fields are in big-endian format on the wire.
FetchAdd操作は、ターゲットメモリのエンディアン形式で実行されます。 「元のリモートデータ値」は、返されるターゲットメモリのエンディアン形式から変換され、リクエスタに返されます。フィールドは、回線上ではビッグエンディアン形式です。
The Requester specifies:
リクエスターは以下を指定します。
o Remote STag
o リモートSTag
o Remote Tagged Offset
o リモートタグ付きオフセット
o Add Data
o データを追加
o Add Mask
o マスクを追加
The Responder returns:
レスポンダは以下を返します：
o Original Remote Data
o 元のリモートデータ
The CmpSwap Atomic Operation requires the Responder to read a 64-bit value at a ULP Buffer address that is 64-bit aligned in the Responder's memory, to perform an AND logical operation using the 64-bit Compare Mask field in the Atomic Operation Request header, then to compare it with the result of a logical AND operation of the Compare Mask and the Compare Data fields in the header. If the two values are equal, the Responder is required to swap masked bits in the same ULP Buffer address with the masked Swap Data. If the two masked compare values are not equal, the contents of the Responder's memory are not changed. In either case, the original value read from the ULP Buffer address is converted from the endian format of the target memory for return and returned to the Requester. The fields are in big-endian format on the wire.
CmpSwapアトミック操作では、アトミック操作要求ヘッダーの64ビットの比較マスクフィールドを使用してAND論理操作を実行するために、レスポンダーがメモリの64ビットに整列されたULPバッファーアドレスで64ビット値を読み取る必要があります次に、それをヘッダーのCompare MaskフィールドとCompare Dataフィールドの論理AND演算の結果と比較します。 2つの値が等しい場合、レスポンダーは同じULPバッファーアドレスのマスクされたビットをマスクされたスワップデータとスワップする必要があります。 2つのマスクされた比較値が等しくない場合、レスポンダのメモリの内容は変更されません。どちらの場合も、ULPバッファーアドレスから読み取られた元の値は、返されるターゲットメモリのエンディアン形式から変換され、リクエスターに返されます。フィールドは、回線上ではビッグエンディアン形式です。
The Requester specifies:
リクエスターは以下を指定します。
o Remote STag
o リモートSTag
o Remote Tagged Offset
o リモートタグ付きオフセット
o Swap Data
o データを入れ替え
o Swap Mask
o マスクの入れ替え
o Compare Data
o データを比較する
o Compare Mask The Responder returns:
o Compare Maskレスポンダは以下を返します：
o Original Remote Data Value
o 元のリモートデータ値
The following pseudocode describes the masked CmpSwap operation result.
次の疑似コードは、マスクされたCmpSwap操作の結果を示しています。
if (!((Compare Data ^ Original Remote Data Value) &
Compare Mask))
マスクを比較））
then
その後
Remote Data Value =
リモートデータ値=
(Original Remote Data Value & ~(Swap Mask))
（元のリモートデータ値＆〜（スワップマスク））
| (Swap Data & Swap Mask)
| （データの入れ替えとマスクの入れ替え）
else
そうしないと
Remote Data Value = Original Remote Data Value
リモートデータ値=元のリモートデータ値
After the operation, the remote data Buffer MUST contain the "Original Remote Data Value" (if comparison did not match) or the masked "Swap Data" (if the comparison did match). CmpSwap Atomic Operations MUST target ULP Buffer addresses that are 64-bit aligned.
操作後、リモートデータバッファーには、「元のリモートデータ値」（比較が一致しなかった場合）またはマスクされた「スワップデータ」（比較が一致した場合）が含まれている必要があります。 CmpSwapアトミック操作は、64ビットで整列されたULPバッファーアドレスをターゲットにする必要があります。
If a CmpSwap Atomic Operation is attempted on a target ULP Buffer address that is not 64-bit aligned:
64ビットに整列されていないターゲットULPバッファーアドレスでCmpSwapアトミック操作が試行された場合：
o The operation MUST NOT be performed,
o 操作を実行してはなりません、
o The Responder's memory MUST NOT be modified,
o レスポンダのメモリは変更してはいけません、
o The result MUST be surfaced as an error, and
o 結果はエラーとして表示されなければなりません。
o A terminate message MUST be generated. (See Section 8.2 for the contents of the terminate message.)
o 終了メッセージを生成する必要があります。 （終了メッセージの内容については、セクション8.2を参照してください。）
The Atomic Operation Request and Response are RDMA Messages. An Atomic Operation makes use of the DDP Untagged Buffer Model. Atomic Operation Request messages MUST use the same Queue Number as RDMA Read Requests (QN=1). Reusing the same Queue Number for Atomic Request messages allows the Atomic Operations to reuse the same infrastructure (e.g., Outbound and Inbound RDMA Read Queue Depth (ORD/IRD) flow control) as defined for RDMA Read Requests. Atomic Operation Response messages MUST set Queue Number (QN) to 3 in the DDP header.
アトミック操作の要求と応答はRDMAメッセージです。アトミック操作は、DDPタグなしバッファーモデルを使用します。アトミック操作要求メッセージは、RDMA読み取り要求（QN = 1）と同じキュー番号を使用する必要があります。アトミックリクエストメッセージに同じキュー番号を再利用することで、アトミックオペレーションは、RDMAリードリクエストに定義されたものと同じインフラストラクチャ（アウトバウンドおよびインバウンドRDMAリードキューデプス（ORD / IRD）フロー制御など）を再利用できます。アトミック操作応答メッセージは、DDPヘッダーのキュー番号（QN）を3に設定する必要があります。
The RDMA Message OpCode for an Atomic Request Message is 1010b. The RDMA Message OpCode for an Atomic Response Message is 1011b.
Atomic RequestメッセージのRDMAメッセージOpCodeは1010bです。 Atomic ResponseメッセージのRDMAメッセージOpCodeは1011bです。
The Atomic Operation Request Message carries an Atomic Operation Header that describes the ULP Buffer address in the Responder's memory. The Atomic Operation Request header immediately follows the DDP header. The RDMAP layer passes to the DDP layer a RDMAP Control Field. The following figure depicts the Atomic Operation Request Header that is used for all Atomic Operation Request Messages:
アトミック操作要求メッセージには、レスポンダのメモリ内のULPバッファアドレスを記述するアトミック操作ヘッダーが含まれています。 Atomic Operation Requestヘッダーは、DDPヘッダーの直後に続きます。 RDMAPレイヤーは、DDPレイヤーにRDMAP制御フィールドを渡します。次の図は、すべてのアトミック操作要求メッセージに使用されるアトミック操作要求ヘッダーを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |AOpCode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Add or Swap Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Add or Swap Mask |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compare Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compare Mask |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Atomic Operation Request Header
図4：アトミック操作要求ヘッダー
Reserved (Not Used): 28 bits
予約済み（未使用）：28ビット
This field is set to zero on transmit, ignored on receive.
このフィールドは送信時にゼロに設定され、受信時には無視されます。
Atomic Operation Code (AOpCode): 4 bits.
原子操作コード（AOpCode）：4ビット。
See Figure 5. All Atomic Operation Codes from Figure 5 MUST be implemented by an RNIC that supports Atomic Operations.
図5を参照してください。図5のすべてのアトミック操作コードは、アトミック操作をサポートするRNICによって実装する必要があります。
Request Identifier: 32 bits.
リクエスト識別子：32ビット。
The Request Identifier specifies a number that is used to identify the Atomic Operation Request Message. The value used in this field is selected by the RNIC that sends the message, and it is reflected back to the Local Peer in the Atomic Operation Response message.
要求IDは、アトミック操作要求メッセージを識別するために使用される番号を指定します。このフィールドで使用される値は、メッセージを送信するRNICによって選択され、アトミック操作応答メッセージでローカルピアに反映されます。
Remote STag: 32 bits.
リモートSTag：32ビット。
The Remote STag identifies the Remote Peer's Tagged Buffer targeted by the Atomic Operation. The Remote STag is associated with the RDMAP Stream through a mechanism that is outside the scope of the RDMAP specification.
リモートSTagは、アトミック操作のターゲットとなるリモートピアのタグ付きバッファを識別します。リモートSTagは、RDMAP仕様の範囲外のメカニズムを介してRDMAPストリームに関連付けられています。
Remote Tagged Offset: 64 bits.
リモートタグ付きオフセット：64ビット。
The Remote Tagged Offset specifies the starting offset, in octets, from the base of the Remote Peer's Tagged Buffer targeted by the Atomic Operation. The Remote Tagged Offset MAY start at an arbitrary offset but MUST represent a ULP Buffer address that is 64-bit aligned.
リモートタグ付きオフセットは、アトミック操作の対象となるリモートピアのタグ付きバッファのベースからの開始オフセットをオクテットで指定します。リモートタグ付きオフセットは、任意のオフセットで開始してもかまいませんが、64ビットでアラインされたULPバッファーアドレスを表す必要があります。
Add or Swap Data: 64 bits.
データの追加または交換：64ビット。
The Add or Swap Data field specifies the 64-bit "Add Data" value in an Atomic FetchAdd Operation or the 64-bit "Swap Data" value in an Atomic Swap or CmpSwap Operation.
Add or Swap Dataフィールドは、Atomic FetchAddオペレーションの64ビットの「Add Data」値、またはAtomic SwapまたはCmpSwapオペレーションの64ビットの「Swap Data」値を指定します。
Add or Swap Mask: 64 bits
マスクの追加または交換：64ビット
This field is used in masked Atomic Operations (FetchAdd and CmpSwap) to perform a bitwise logical AND operation as specified in the definition of these operations. For non-masked Atomic Operations (Swap), this field is set to ffffffffffffffffh on transmit and ignored by the receiver.
このフィールドは、マスクされたアトミック操作（FetchAddおよびCmpSwap）で使用され、これらの操作の定義で指定されているビットごとの論理AND操作を実行します。マスクされていないアトミック操作（スワップ）の場合、このフィールドは送信時にffffffffffffffffhに設定され、受信側では無視されます。
Compare Data: 64 bits.
データの比較：64ビット。
The Compare Data field specifies the 64-bit "Compare Data" value in an Atomic CmpSwap Operation. For Atomic Operations FetchAdd and Atomic Swap, the Compare Data field is set to zero on transmit and ignored by the receiver.
Compare Dataフィールドは、Atomic CmpSwap操作の64ビットの「Compare Data」値を指定します。 Atomic Operations FetchAddおよびAtomic Swapの場合、Compare Dataフィールドは送信時にゼロに設定され、レシーバーによって無視されます。
Compare Mask: 64 bits
比較マスク：64ビット
This field is used in masked Atomic Operation CmpSwap to perform a bitwise logical AND operation as specified in the definition of these operations. For Atomic Operations FetchAdd and Swap, this field is set to ffffffffffffffffh on transmit and ignored by the receiver.
このフィールドは、マスクされたアトミック操作CmpSwapで使用され、これらの操作の定義で指定されているビット単位の論理AND操作を実行します。 Atomic Operations FetchAdd and Swapの場合、このフィールドは送信時にffffffffffffffffhに設定され、レシーバーによって無視されます。
---------+-----------+----------+----------+---------+---------
Atomic | Atomic | Add or | Add or | Compare | Compare
Operation| Operation | Swap | Swap | Data | Mask
Code | | Data | Mask | |
---------+-----------+----------+----------+---------+---------
0000b | FetchAdd | Add Data | Add Mask | N/A | N/A
---------+-----------+----------+----------+---------+---------
0010b | CmpSwap | Swap Data| Swap Mask| Valid | Valid
---------+-----------+-----------------------------------------
Figure 5: Atomic Operation Message Definitions
図5：アトミック操作メッセージ定義
The Atomic Operation Request Message has the following semantics:
アトミック操作要求メッセージには、次のセマンティクスがあります。
1. An Atomic Operation Request Message MUST reference an Untagged Buffer. That is, the Local Peer's RDMAP layer MUST request that the DDP mark the Message as Untagged.
1. アトミック操作要求メッセージは、タグなしバッファを参照する必要があります。つまり、ローカルピアのRDMAPレイヤーは、DDPがメッセージをタグなしとしてマークすることを要求する必要があります。
2. One Atomic Operation Request Message MUST consume one Untagged Buffer.
2. 1つのアトミック操作要求メッセージは、1つのタグなしバッファを使用する必要があります。
3. The Responder's RDMAP layer MUST process an Atomic Operation Request Message. A valid Atomic Operation Request Message MUST NOT be delivered to the Responder's ULP (i.e., it is processed by the RDMAP layer).
3. レスポンダーのRDMAPレイヤーは、アトミック操作要求メッセージを処理する必要があります。有効なアトミック操作要求メッセージは、レスポンダーのULPに配信してはなりません（つまり、RDMAPレイヤーで処理されます）。
4. At the Responder, an error MUST be surfaced in response to delivery to the Remote Peer's RDMAP layer of an Atomic Operation Request Message with an Atomic Operation Code that the RNIC does not support.
4. レスポンダでは、RNICがサポートしていないアトミック操作コードを含むアトミック操作要求メッセージのリモートピアのRDMAPレイヤーへの配信に応答してエラーが発生する必要があります。
5. An Atomic Operation Request Message MUST reference the RDMA Read Request Queue. That is, the Requester's RDMAP layer MUST request that the DDP layer set the Queue Number field to one.
5. アトミック操作要求メッセージは、RDMA読み取り要求キューを参照する必要があります。つまり、リクエスターのRDMAPレイヤーは、DDPレイヤーがキュー番号フィールドを1に設定することを要求する必要があります。
6. The Requester MUST pass to the DDP layer Atomic Operation Request Messages in the order they were submitted by the ULP.
6. リクエスタは、ULPから送信された順序でDDP層の原子操作要求メッセージに渡す必要があります。
7. The Responder MUST process the Atomic Operation Request Messages in the order they were sent.
7. レスポンダは、送信された順序でアトミック操作要求メッセージを処理する必要があります。
8. If the Responder receives a valid Atomic Operation Request Message, it MUST respond with a valid Atomic Operation Response Message.
8. レスポンダが有効な原子操作要求メッセージを受信した場合、有効な原子操作応答メッセージで応答する必要があります。
The Atomic Operation Response Message carries an Atomic Operation Response Header that contains the "Original Request Identifier" and "Original Remote Data Value". The Atomic Operation Response Header immediately follows the DDP header. The RDMAP layer passes to the DDP layer a RDMAP Control Field. The following figure depicts the Atomic Operation Response header that is used for all Atomic Operation Response Messages:
アトミック操作応答メッセージには、「元の要求識別子」と「元のリモートデータ値」を含むアトミック操作応答ヘッダーが含まれています。 Atomic Operation Responseヘッダーは、DDPヘッダーの直後に続きます。 RDMAPレイヤーは、DDPレイヤーにRDMAP制御フィールドを渡します。次の図は、すべてのアトミック操作応答メッセージに使用されるアトミック操作応答ヘッダーを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Remote Data Value |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Atomic Operation Response Header
図6：アトミック操作応答ヘッダー
Original Request Identifier: 32 bits.
元のリクエスト識別子：32ビット。
The Original Request Identifier is set to the value specified in the Request Identifier field that was originally provided in the corresponding Atomic Operation Request Message.
Original Request Identifierは、対応するAtomic Operation Requestメッセージで最初に提供されたRequest Identifierフィールドで指定された値に設定されます。
Original Remote Data Value: 64 bits.
元のリモートデータ値：64ビット。
The Original Remote Value specifies the original 64-bit value stored at the ULP Buffer address targeted by the Atomic Operation.
元のリモート値は、アトミック操作の対象となるULPバッファーアドレスに格納されている元の64ビット値を指定します。
The Atomic Operation Response Message has the following semantics:
アトミック操作応答メッセージには、次の意味があります。
1. The Atomic Operation Response Message for the associated Atomic Operation Request Message travels in the opposite direction.
1. 関連するアトミック操作要求メッセージのアトミック操作応答メッセージは、反対方向に移動します。
2. An Atomic Operation Response Message MUST consume an Untagged Buffer. That is, the Responder RDMAP layer MUST request that the DDP mark the Message as Untagged.
2. アトミック操作応答メッセージはタグなしバッファを消費する必要があります。つまり、レスポンダRDMAPレイヤーは、DDPがメッセージをタグなしとしてマークすることを要求する必要があります。
3. An Atomic Operation Response Message MUST reference the Queue Number 3. That is, the Responder's RDMAP layer MUST request that the DDP layer set the Queue Number field to 3.
3. アトミック操作応答メッセージはキュー番号3を参照する必要があります。つまり、レスポンダーのRDMAPレイヤーは、DDPレイヤーがキュー番号フィールドを3に設定することを要求する必要があります。
4. The Responder MUST ensure that a sufficient number of Untagged Buffers are available on the RDMA Read Request Queue (Queue with DDP Queue Number 1) to support the maximum number of Atomic Operation Requests negotiated by the ULP in addition to the maximum number of RDMA Read Requests negotiated by the ULP.
4. レスポンダは、RDMA読み取り要求の最大数に加えて、ULPによってネゴシエートされるアトミック操作要求の最大数をサポートするために、RDMA読み取り要求キュー（DDPキュー番号1のキュー）で十分な数のタグなしバッファが利用できることを確認する必要があります。 ULPによって交渉されました。
5. The Requester MUST ensure that a sufficient number of Untagged Buffers are available on the RDMA Atomic Response Queue (Queue with DDP Queue Number 3) to support the maximum number of Atomic Operation Requests negotiated by the ULP.
5. リクエスターは、ULPによってネゴシエートされるアトミック操作要求の最大数をサポートするために、十分な数のタグなしバッファーがRDMAアトミック応答キュー（DDPキュー番号3のキュー）で利用可能であることを確認する必要があります。
6. The RDMAP layer MUST Deliver the Atomic Operation Response Message to the ULP.
6. RDMAP層は、原子操作応答メッセージをULPに配信する必要があります。
7. At the Requester, when an invalid Atomic Operation Response Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced.
7. リクエスターで、無効なアトミック操作応答メッセージがリモートピアのRDMAPレイヤーに配信されると、エラーが発生します。
8. When the Responder receives Atomic Operation Request messages, the Responder RDMAP layer MUST pass Atomic Operation Response Messages to the DDP layer, in the order that the Atomic Operation Request Messages were received by the RDMAP layer, at the Responder.
8. レスポンダがアトミック操作要求メッセージを受信すると、レスポンダのRDMAP層がアトミック操作要求メッセージを受信した順序で、レスポンダのRDMAP層がアトミック操作応答メッセージをDDP層に渡さなければなりません（MUST）。
Atomicity of the Read-Modify-Write (RMW) on the Responder's node by the Atomic Operation MUST be assured in the context of concurrent atomic accesses by other RDMAP Streams on the same RNIC.
アトミック操作によるレスポンダのノードでの読み取り-変更-書き込み（RMW）のアトミック性は、同じRNIC上の他のRDMAPストリームによる同時アトミックアクセスのコンテキストで保証される必要があります。
In addition to the ordering and completion rules described in RFC 5040, the following rules apply to implementations of the Atomic Operations.
RFC 5040で説明されている順序付けと完了のルールに加えて、次のルールがアトミック操作の実装に適用されます。
1. For an Atomic Operation, the Requester MUST NOT consider the contents of the Tagged Buffer at the Responder to be modified by that specific Atomic Operation until the Atomic Operation Response Message has been Delivered to RDMAP at the Requester.
1. アトミック操作の場合、リクエスターは、アトミック操作の応答メッセージがリクエスターでRDMAPに配信されるまで、レスポンダーのタグ付きバッファーの内容がその特定のアトミック操作によって変更されることを考慮してはなりません。
2. Atomicity guarantees MUST be provided within the scope of a single RNIC.
2. 原子性の保証は、単一のRNICの範囲内で提供する必要があります。
Implementation Note: This requirement for atomicity among operations is limited to the scope of a single RNIC. Atomicity guarantees are OPTIONAL with respect to access to the Tagged Buffer by any other method than an Atomic Operation via the same RNIC. Examples of such accesses that may not be atomic with respect to an Atomic Operation include accesses via other RNICs and local processor memory access to the Tagged Buffer.
実装上の注意：この操作間の原子性の要件は、単一のRNICの範囲に限定されます。原子性の保証は、同じRNICを介した原子操作以外の方法によるタグ付きバッファへのアクセスに関してはオプションです。アトミック操作に関してアトミックでない可能性があるそのようなアクセスの例には、他のRNICを介したアクセス、およびタグ付きバッファーへのローカルプロセッサメモリアクセスが含まれます。
3. Atomic Operation Request Messages MUST NOT start processing at the Responder until they have been Delivered to RDMAP by DDP.
3. アトミック操作要求メッセージは、DDPによってRDMAPに配信されるまで、レスポンダで処理を開始してはなりません。
4. Atomic Operation Response Messages MAY be generated at the Responder after subsequent RDMA Write Messages or Send Messages have been Placed or Delivered.
4. アトミック操作応答メッセージは、後続のRDMA書き込みメッセージまたは送信メッセージが配置または配信された後に、レスポンダーで生成される場合があります。
5. Atomic Operation Response Message processing at the Responder MUST be started only after the Atomic Operation Request Message has been Delivered by the DDP layer (thus, all previous RDMA Messages on that DDP Stream have been Delivered).
5. レスポンダでのアトミック操作応答メッセージの処理は、DDPレイヤーによってアトミック操作要求メッセージが配信された後にのみ開始する必要があります（したがって、そのDDPストリーム上の以前のすべてのRDMAメッセージが配信されました）。
6. Send Messages MAY be Completed at the Responder before prior incoming Atomic Operation Request Messages have completed their response processing.
6. 前の着信原子操作要求メッセージが応答処理を完了する前に、メッセージの送信が応答側で完了する場合があります。
7. An Atomic Operation MUST NOT be Completed at the Requester until the DDP layer Delivers the associated incoming Atomic Operation Response Message.
7. アトミック操作は、DDPレイヤーが関連する着信アトミック操作応答メッセージを配信するまで、リクエスターで完了してはなりません（MUST NOT）。
8. If more than one outstanding Atomic Request Message is supported by both peers, the Atomic Operation Request Messages MUST be processed in the order they were delivered by the DDP layer on the Responder. Atomic Operation Response Messages MUST be submitted to the DDP layer on the Responder in the order the Atomic Operation Request Messages were Delivered by DDP.
8. 両方のピアで複数の未処理のアトミック要求メッセージがサポートされている場合、アトミック操作要求メッセージは、レスポンダのDDP層によって配信された順序で処理する必要があります。原子操作応答メッセージは、原子操作要求メッセージがDDPによって配信された順序でレスポンダのDDP層に送信する必要があります。
The Immediate Data operation is typically used in conjunction with an RDMA Write Operation to improve ULP processing efficiency. The efficiency is gained by causing an RDMA Completion to be generated immediately following the RDMA Write operation. This RDMA Completion delivers 8 bytes of Immediate Data at the Remote Peer. The combination of an RDMA Write Message followed by an Immediate Data Operation has the same behavior as the RDMA Write with Immediate Data operation found in InfiniBand. An Immediate Data operation that is not preceded by an RDMA Write operation causes an RDMA Completion.
即時データ操作は通常、ULP処理効率を向上させるためにRDMA書き込み操作と組み合わせて使用されます。効率は、RDMA書き込み操作の直後にRDMA完了を生成することで得られます。このRDMA完了は、リモートピアで8バイトの即時データを配信します。 RDMA書き込みメッセージとそれに続く即時データ操作の組み合わせは、InfiniBandにあるRDMA書き込みと即時データ操作と同じ動作をします。 RDMA書き込み操作が先行しない即時データ操作は、RDMA完了を引き起こします。
For Immediate Data operations, the following are the interactions between the RDMAP Layer and the ULP:
即時データ操作の場合、RDMAPレイヤーとULPの間の相互作用は次のとおりです。
o At the Data Source:
o データソース：
- The ULP passes to the RDMAP Layer the following:
- ULPは、次のものをRDMAPレイヤーに渡します。
* 8 bytes of ULP Immediate Data
* 8バイトのULP即時データ
- When the Immediate Data operation Completes, an indication of the Completion results.
- 即時データ操作が完了すると、完了の結果が表示されます。
o At the Data Sink:
o データシンクで：
- If the Immediate Data operation is Completed successfully, the RDMAP Layer passes the following information to the ULP Layer:
- 即時データ操作が正常に完了した場合、RDMAPレイヤーは次の情報をULPレイヤーに渡します。
* 8 bytes of Immediate Data
* 8バイトの即時データ
* An Event, if the Data Sink is configured to generate an Event.
* イベント（データシンクがイベントを生成するように構成されている場合）。
- If the Immediate Data operation is Completed in error, the Data Sink RDMAP Layer will pass up the corresponding error information to the Data Sink ULP and send a Terminate Message to the Data Source RDMAP Layer. The Data Source RDMAP Layer will then pass up the Terminate Message to the ULP.
- 即時データ操作がエラーで完了した場合、Data Sink RDMAPレイヤーは対応するエラー情報をData Sink ULPに渡し、TerminateメッセージをData Source RDMAPレイヤーに送信します。データソースのRDMAPレイヤーは、終了メッセージをULPに渡します。
The Immediate Data and Immediate Data with SE Messages carry Immediate Data as shown in Figure 7. The RDMAP layer passes to the DDP layer an RDMAP Control Field and 8 bytes of Immediate Data. The first 8 bytes of the data following the DDP header contains the Immediate Data. See Appendix A.3 for the DDP segment format of an Immediate Data or Immediate Data with SE Message.
図7に示すように、イミディエイトデータとSEメッセージ付きイミディエイトデータはイミディエイトデータを伝送します。RDMAPレイヤーは、DDPレイヤーにRDMAPコントロールフィールドと8バイトのイミディエイトデータを渡します。 DDPヘッダーに続くデータの最初の8バイトには、即時データが含まれています。即時データまたはSEメッセージ付きの即時データのDDPセグメント形式については、付録A.3を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Immediate Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Immediate Data or Immediate Data with SE Message Header
図7：即時データまたはSEメッセージヘッダー付きの即時データ
Immediate Data: 64 bits. 8 bytes of data transferred from the Data Source to an untagged Buffer at the Data Sink.
即時データ：64ビット。データソースからデータシンクのタグなしバッファに転送される8バイトのデータ。
The Immediate Data or Immediate Data with SE Message uses the DDP Untagged Buffer Model to transfer Immediate Data from the Data Source to the Data Sink.
イミディエイトデータまたはSEメッセージ付きイミディエイトデータは、DDPタグなしバッファモデルを使用して、イミディエイトデータをデータソースからデータシンクに転送します。
o An Immediate Data or Immediate Data with SE Message MUST reference an Untagged Buffer. That is, the Local Peer's RDMAP Layer MUST request that the DDP layer mark the Message as Untagged.
o 即時データまたはSEメッセージ付きの即時データは、タグなしバッファを参照する必要があります。つまり、ローカルピアのRDMAPレイヤーは、DDPレイヤーがメッセージをタグなしとしてマークすることを要求する必要があります。
o One Immediate Data or Immediate Data with SE Message MUST consume one Untagged Buffer.
o 1つのイミディエイトデータまたはSEメッセージ付きのイミディエイトデータは、1つのタグなしバッファを使用する必要があります。
o At the Remote Peer, the Immediate Data and Immediate Data with SE Messages MUST be Delivered to the Remote Peer's ULP in the order they were sent.
o リモートピアでは、イミディエイトデータとSEメッセージ付きのイミディエイトデータを、送信された順序でリモートピアのULPに配信する必要があります。
o For an Immediate Data or Immediate Data with SE Message, the Local Peer's RDMAP Layer MUST request that the DDP layer set the Queue Number field to zero.
o 即時データまたはSEメッセージ付きの即時データの場合、ローカルピアのRDMAPレイヤーは、DDPレイヤーがキュー番号フィールドをゼロに設定することを要求する必要があります。
o For an Immediate Data or Immediate Data with SE Message, the Local Peer's RDMAP Layer MUST request that the DDP layer transmit 8 bytes of data.
o 即時データまたはSEメッセージ付きの即時データの場合、ローカルピアのRDMAP層は、DDP層が8バイトのデータを送信することを要求する必要があります。
o The Local Peer MUST issue Immediate Data and Immediate Data with SE Messages in the order they were submitted by the ULP.
o ローカルピアは、ULPから送信された順序で、即時メッセージと即時データをSEメッセージで発行する必要があります。
o The Remote Peer MUST check that Immediate Data and Immediate Data with SE Messages include exactly 8 bytes of data from the DDP layer. The DDP header carries the length field that is reported by the DDP layer.
o リモートピアは、イミディエイトデータおよびSEメッセージ付きイミディエイトデータにDDPレイヤーからの正確に8バイトのデータが含まれていることを確認する必要があります。 DDPヘッダーには、DDPレイヤーによって報告される長さフィールドが含まれています。
Ordering and completion rules for Immediate Data are the same as those for a Send operation as described in Section 5.5 of RFC 5040.
即時データの順序付けと完了のルールは、RFC 5040のセクション5.5で説明されている送信操作の場合と同じです。
The following table summarizes the ordering relationships for Atomic and Immediate Data operations from the standpoint of the Local Peer issuing the Operations. Note that in the table that follows, Send includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate. Also note that in the table below, Immediate Data includes Immediate Data and Immediate Data with Solicited Event.
次の表は、オペレーションを発行するローカルピアの観点から見た、アトミックおよび即時データオペレーションの順序関係をまとめたものです。次の表では、送信には送信、無効化して送信、送信請求イベントで送信、送信請求イベントと無効化送信が含まれていることに注意してください。また、以下の表では、即時データには即時データと要請イベントのある即時データが含まれていることにも注意してください。
---------+----------+-------------+-------------+------------------
First | Second | Placement | Placement | Ordering
Operation| Operation| Guarantee at| Guarantee at| Guarantee at
| | Remote Peer | Local Peer | Remote Peer
---------+----------+-------------+-------------+------------------
Immediate| Send | No Placement| Not | Completed in
Data | | Guarantee | Applicable | Order
| | between Send| |
| | Payload and | |
| | Immediate | |
| | Data | |
---------+----------+-------------+-------------+------------------
Immediate| RDMA | No Placement| Not | Not
Data | Write | Guarantee | Applicable | Applicable
| | between RDMA| |
| | Write | |
| | Payload and | |
| | Immediate | |
| | Data | |
---------+----------+-------------+-------------+------------------
Immediate| RDMA | No Placement| RDMA Read | RDMA Read
Data | Read | Guarantee | Response | Response
| | between | will not be | Message will
| | Immediate | Placed until| not be
| | Data and | Immediate | generated
| | RDMA Read | Data is | until
| | Request | Placed at | Immediate Data
| | | Remote Peer | has been
| | | | Completed
---------+----------+-------------+-------------+------------------
Immediate| Atomic | No Placement| Atomic | Atomic
Data | | Guarantee | Response | Response
| | between | will not be | Message will
| | Immediate | Placed until| not be
| | Data and | Immediate | generated
| | Atomic | Data is | until
| | Request | Placed at | Immediate Data
| | | Remote Peer | has been
| | | | Completed
---------+----------+-------------+-------------+------------------
Immediate| Immediate| No Placement| Not | Completed in
Data or | Data | Guarantee | Applicable | Order
Send | | | |
---------+----------+-------------+-------------+------------------
RDMA | Immediate| No Placement| Not | Immediate Data
Write | Data | Guarantee | Applicable | is Completed
| | | | after RDMA
| | | | Write is Placed
| | | | and Delivered
---------+----------+-------------+-------------+------------------
RDMA Read| Immediate| No Placement| Immediate | Not Applicable
| Data | Guarantee | Data MAY be |
| | between | Placed |
| | Immediate | before |
| | Data and | RDMA Read |
| | RDMA Read | Response is |
| | Request | generated |
---------+----------+-------------+-------------+------------------
Atomic | Immediate| No Placement| Immediate | Not Applicable
| Data | Guarantee | Data MAY be |
| | between | Placed |
| | Immediate | before |
| | Data and | Atomic |
| | Atomic | Response is |
| | Request | generated |
---------+----------+-------------+-------------+------------------
Atomic | Send | No Placement| Send Payload| Not Applicable
| | Guarantee | MAY be |
| | between Send| Placed |
| | Payload and | before |
| | Atomic | Atomic |
| | Request | Response is |
| | | generated |
---------+----------+-------------+-------------+------------------
Atomic | RDMA | No Placement| RDMA Write | Not
| Write | Guarantee | Payload MAY | Applicable
| | between RDMA| be Placed |
| | Write | before |
| | Payload and | Atomic |
| | Atomic | Response is |
| | Request | generated |
---------+----------+-------------+-------------+------------------
Atomic | RDMA | No Placement| No Placement| RDMA Read
| Read | Guarantee | Guarantee | Response
| | between | between | Message will
| | Atomic | Atomic | not be
| | Request and | Response | generated
| | RDMA Read | and RDMA | until Atomic
| | Request | Read | Response Message
| | | Response | has been
| | | | generated
---------+----------+-------------+-------------+------------------
Atomic | Atomic | Placed in | No Placement| Second Atomic
| | order | Guarantee | Request
| | | between two | Message will
| | | Atomic | not be
| | | Responses | processed
| | | | until first
| | | | Atomic Response
| | | | has been
| | | | generated
---------+----------+-------------+-------------+------------------
Send | Atomic | No Placement| Atomic | Atomic Response
| | Guarantee | Response | Message will not
| | between Send| will not be | be generated
| | Payload and | Placed at | until Send has
| | Atomic | the Local | been Completed
| | Request | Peer until |
| | | Send Payload|
| | | is Placed |
| | | at the |
| | | Remote Peer |
---------+----------+-------------+-------------+------------------
RDMA | Atomic | No Placement| Atomic | Not
Write | | Guarantee | Response | Applicable
| | between RDMA| will not be |
| | Write | Placed at |
| | Payload and | the Local |
| | Atomic | Peer until |
| | Request | RDMA Write |
| | | Payload |
| | | is Placed |
| | | at the |
| | | Remote Peer |
---------+----------+-------------+-------------+------------------
RDMA | Atomic | No Placement| No Placement| Atomic Response
Read | | Guarantee | Guarantee | Message will
| | between | between | not be generated
| | Atomic | Atomic | until RDMA
| | Request and | Response | Read Response
| | RDMA Read | and RDMA | has been
| | Request | Read | generated
| | | Response |
---------+----------+-------------+-------------+------------------
In addition to the error processing described in Section 7 of RFC 5040, the following rules apply for the new RDMA Messages defined in this specification.
RFC 5040のセクション7で説明されているエラー処理に加えて、この仕様で定義されている新しいRDMAメッセージには次のルールが適用されます。
The Local Peer MUST send a Terminate Message for each of the following cases:
ローカルピアは、次の各ケースについて終了メッセージを送信する必要があります。
1. For errors detected while creating an Atomic Request, Atomic Response, Immediate Data, or Immediate Data with SE Message, or other reasons not directly associated with an incoming Message, the Terminate Message and Error code are sent instead of the Message. In this case, the Error Type and Error Code fields are included in the Terminate Message, but the Terminated DDP Header and Terminated RDMA Header fields are set to zero.
1. アトミックリクエスト、アトミックレスポンス、即時データ、またはSEメッセージを含む即時データの作成中に検出されたエラー、または着信メッセージに直接関連付けられていない他の理由の場合、メッセージの代わりに終了メッセージとエラーコードが送信されます。この場合、エラータイプフィールドとエラーコードフィールドは終了メッセージに含まれますが、終了DDPヘッダーフィールドと終了RDMAヘッダーフィールドはゼロに設定されます。
2. For errors detected on an incoming Atomic Request, Atomic Response, Immediate Data, or Immediate Data with SE (after the Message has been Delivered by DDP), the Terminate Message is sent at the earliest possible opportunity, preferably in the next outgoing RDMA Message. In this case, the Error Type, Error Code, and Terminated DDP Header fields are included in the Terminate Message, but the Terminated RDMA Header field is set to zero.
2.着信アトミックリクエスト、アトミックレスポンス、イミディエイトデータ、またはSEを備えたイミディエイトデータで検出されたエラー（メッセージがDDPによって配信された後）の場合、ターミネートメッセージはできるだけ早く、できれば次の発信RDMAで送信されますメッセージ。この場合、エラータイプ、エラーコード、および終了DDPヘッダーフィールドは終了メッセージに含まれますが、終了RDMAヘッダーフィールドはゼロに設定されます。
On incoming Atomic Requests, Atomic Responses, Immediate Data, and Immediate Data with Solicited Event, the following MUST be validated:
着信アトミックリクエスト、アトミックレスポンス、即時データ、および要請イベントを伴う即時データでは、以下を検証する必要があります。
o The DDP layer MUST validate all DDP Segment fields.
o DDPレイヤーは、すべてのDDPセグメントフィールドを検証する必要があります。
o The RDMA OpCode MUST be valid.
o RDMA OpCodeは有効でなければなりません。
o The RDMA Version MUST be valid.
o RDMAバージョンは有効でなければなりません。
On incoming Atomic requests the following additional validation MUST be performed:
着信Atomicリクエストでは、次の追加の検証を実行する必要があります。
o The RDMAP layer MUST validate that the Remote Peer's Tagged ULP Buffer address references a ULP Buffer address that is 64-bit aligned. In the case of an error, the RDMAP layer MUST generate a Terminate Message indicating RDMA Layer Remote Operation Error with Error Code Name "Catastrophic error, localized to RDMAP Stream" as described in Section 4.8 of RFC 5040. Implementation Note: A ULP implementation can avoid this error by having the target ULP Buffer of an Atomic Operation 64-bit aligned.
o RDMAPレイヤーは、リモートピアのタグ付きULPバッファーアドレスが64ビットに揃えられたULPバッファーアドレスを参照していることを検証する必要があります。エラーの場合、RDMAPレイヤーは、RFC 5040のセクション4.8で説明されているように、エラーコード名「Catastrophic error、localized to RDMAP Stream」でRDMAレイヤーリモート操作エラーを示す終了メッセージを生成する必要があります。アトミック操作のターゲットULPバッファーを64ビットに揃えることで、このエラーを回避します。
This document specifies extensions to the RDMA Protocol specification in RFC 5040, and as such the Security Considerations discussed in Section 8 of RFC 5040 apply. In particular, Atomic Operations use ULP Buffer addresses for the Remote Peer Buffer addressing used in RFC 5040 as required by the security model described in RFC 5042 [RFC5042].
このドキュメントでは、RFC 5040のRDMAプロトコル仕様の拡張を指定しているため、RFC 5040のセクション8で説明されているセキュリティに関する考慮事項が適用されます。特に、Atomic Operationsは、RFC 5042 [RFC5042]で説明されているセキュリティモデルで要求されているように、RFC 5040で使用されるリモートピアバッファアドレス指定にULPバッファアドレスを使用します。
RDMAP and related protocols may be used by applications that exhibit distinctive traffic characteristics such as message timing, source, destination, and size patterns. Examples include structured high-performance computing applications based on the MPI interface. For such applications, analysis of encrypted traffic could reveal sensitive information, e.g., the nature of the application, size of data set being used, and information about the application's rate of progress. Such information can be hidden from passive observation via use of Encapsulating Security Payload version 3 (ESPv3) Traffic Flow Confidentiality [RFC4303] to obfuscate the encrypted traffic's characteristics. ESPv3 implementation requirements for RDMAP are specified in [RFC7146].
RDMAPと関連プロトコルは、メッセージのタイミング、送信元、宛先、サイズパターンなどの特徴的なトラフィック特性を示すアプリケーションで使用できます。例には、MPIインターフェイスに基づく構造化された高性能コンピューティングアプリケーションが含まれます。このようなアプリケーションの場合、暗号化されたトラフィックを分析すると、機密情報（アプリケーションの性質、使用されているデータセットのサイズ、アプリケーションの進行速度に関する情報など）が明らかになる可能性があります。暗号化されたトラフィックの特性を難読化するために、Encapsulating Security Payload version 3（ESPv3）Traffic Flow Confidentiality [RFC4303]を使用することにより、このような情報を受動的な監視から隠すことができます。 RDMAPのESPv3実装要件は、[RFC7146]で指定されています。
IANA has added the following entries to the "RDMAP Message Operation Codes" registry of "Remote Direct Data Placement (RDDP)" registry:
IANAは、「Remote Direct Data Placement（RDDP）」レジストリの「RDMAP Message Operation Codes」レジストリに次のエントリを追加しました。
0x8, Immediate Data, this specification
0x8、即時データ、この仕様
0x9, Immediate Data with Solicited Event, this specification
0x9、要請イベントのある即時データ、この仕様
0xA, Atomic Request, this specification
0xA、Atomic Request、この仕様
0xB, Atomic Response, this specification
0xB、Atomic Response、この仕様
In addition, the following registry has been added to the "Remote Direct Data Placement (RDDP)" registry. The following section specifies the registry, its initial contents, and the administration policy in more detail.
さらに、次のレジストリが「リモート直接データ配置（RDDP）」レジストリに追加されました。次のセクションでは、レジストリ、その初期コンテンツ、および管理ポリシーについて詳しく説明します。
Name of the registry: "RDMAP Message Atomic Operation Subcodes"
レジストリの名前：「RDMAPメッセージアトミック操作サブコード」
Namespace details: RDMAP Message Atomic Operation Subcodes are 4-bit values.
名前空間の詳細：RDMAPメッセージのアトミック操作サブコードは4ビット値です。
Information that must be provided to assign a new value: An IESG-approved Standards Track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しい値のセマンティクスと相互運用性の要件、およびレジストリに記録されるフィールドを定義するIESG承認のStandards Track仕様。
Fields to record in the registry: RDMAP Message Atomic Operation Subcode, Atomic Operation, RFC Reference.
レジストリに記録するフィールド：RDMAPメッセージアトミック操作サブコード、アトミック操作、RFCリファレンス。
Initial registry contents:
レジストリの初期内容：
0x0, FetchAdd, this specification
0x0、FetchAdd、この仕様
0x1, Reserved, this specification
0x1、予約済み、この仕様
0x2, CmpSwap, this specification
0x2、CmpSwap、この仕様
Note: An experimental RDMAP Message Operation Code has already been allocated; hence, there is no need for an experimental RDMAP Message Atomic Operation Subcode.
注：実験的なRDMAPメッセージ操作コードがすでに割り当てられています。したがって、実験的なRDMAPメッセージアトミック操作サブコードは必要ありません。
All other values are Unassigned and available to IANA for assignment. New RDMAP Message Atomic Operation Subcodes should be assigned sequentially in order to better support implementations that process RDMAP Message Atomic Operations in hardware.
他のすべての値は未割り当てで、IANAが割り当てに使用できます。ハードウェアでRDMAPメッセージアトミック操作を処理する実装をより適切にサポートするには、新しいRDMAPメッセージアトミック操作サブコードを順番に割り当てる必要があります。
Allocation Policy: Standards Action [RFC5226]
割り当てポリシー：標準アクション[RFC5226]
Name of the registry: "RDMAP DDP Untagged Queue Numbers"
レジストリの名前：「RDMAP DDP Untagged Queue Numbers」
Namespace details: RDMAP DDP Untagged Queue numbers are 32-bit values.
名前空間の詳細：RDMAP DDPタグなしキュー番号は32ビット値です。
Information that must be provided to assign a new value: An IESG-approved Standards Track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
新しい値を割り当てるために提供する必要がある情報：提案された新しい値のセマンティクスと相互運用性の要件、およびレジストリに記録されるフィールドを定義するIESG承認のStandards Track仕様。
Fields to record in the registry: RDMAP DDP Untagged Queue Numbers, Queue Usage Description, RFC Reference.
レジストリに記録するフィールド：RDMAP DDPタグなしのキュー番号、キューの使用法の説明、RFCリファレンス。
Initial registry contents:
レジストリの初期内容：
0x00000000, Queue 0 (Send operation Variants), [RFC5040]
0x00000000、キュー0（操作バリアントの送信）、[RFC5040]
0x00000001, Queue 1 (RDMA Read Request operations), [RFC5040]
0x00000001、キュー1（RDMA読み取り要求操作）、[RFC5040]
0x00000002, Queue 2 (Terminate operations), [RFC5040]
0x00000002、キュー2（操作の終了）、[RFC5040]
0x00000003, Queue 3 (Atomic Response operations), this specification
0x00000003、キュー3（アトミックレスポンス操作）、この仕様
Note: An experimental RDMAP Message Operation Code has already been allocated; hence, there is no need for an experimental RDMAP DDP Untagged Queue Number.
注：実験的なRDMAPメッセージ操作コードがすでに割り当てられています。したがって、実験的なRDMAP DDPタグなしキュー番号は必要ありません。
All other values are Unassigned and available to IANA for assignment. New RDMAP queue numbers should be assigned sequentially in order to better support implementations that perform RDMAP queue selection in hardware.
他のすべての値は未割り当てで、IANAが割り当てに使用できます。ハードウェアでRDMAPキュー選択を実行する実装をより適切にサポートするには、新しいRDMAPキュー番号を順番に割り当てる必要があります。
Allocation Policy: Standards Action [RFC5226]
割り当てポリシー：標準アクション[RFC5226]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RFC5040] Recio、R.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「A Remote Direct Memory Access Protocol Specification」、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「Reliable Transportsを介した直接データ配置」、RFC 5041、2007年10月。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RFC5042] Pinkerton、J。およびE. Deleganes、「Direct Data Placement Protocol（DDP）/ Remote Direct Memory Access Protocol（RDMAP）Security」、RFC 5042、2007年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, April 2014.
[RFC7146] Black、D。、およびP. Koning、「IPを介したブロックストレージプロトコルの保護：IPsec v3のRFC 3723要件の更新」、RFC 7146、2014年4月。
[DAT_ATOMICS] DAT Collaborative, "IB Transport Specific Extensions for DAT 2.0", User Direct Access Programming Library, <http://www.datcollaborative.org/DAT_IB_Extensions.pdf>.
[DAT_ATOMICS] DAT Collaborative、「IB Transport Specific Extensions for DAT 2.0」、ユーザーダイレクトアクセスプログラミングライブラリ、<http://www.datcollaborative.org/DAT_IB_Extensions.pdf>。
[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification Volumes 1 and 2", Release 1.1, November 2002, <http://www.infinibandta.org/specs>.
[IB] InfiniBand Trade Association、「InfiniBand Architecture Specification Volume 1 and 2」、リリース1.1、2002年11月、<http://www.infinibandta.org/specs>。
[MPI] Message Passing Interface Forum, "MPI: A Message-Passing Interface Standard, Version 3.0", September 2012, <http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf>.
[MPI]メッセージパッシングインターフェースフォーラム、「MPI：A Message-Passing Interface Standard、Version 3.0」、2012年9月、<http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf> 。
[OFAVERBS] Rosenstock, H., "Subject: Re: [PATCH 0/2] Add support for enhanced atomic operations", message to the linux-rdma mailing list, <http://www.spinics.net/lists/linux-rdma/msg02405.html>.
[OFAVERBS] Rosenstock、H。、「件名：Re：[パッチ0/2]拡張アトミック操作のサポートを追加」、linux-rdmaメーリングリストへのメッセージ、<http://www.spinics.net/lists/linux -rdma / msg02405.html>。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007.
[RFC5044] Culley、P.、Elzur、U.、Recio、R.、Bailey、S.、J。Carrier、「Marker PDU Aligned Framing for TCP Specification」、RFC 5044、2007年10月
[RFC5045] Bestler, C., Ed., and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007.
[RFC5045] Bestler、C.、Ed。、およびL. Coene、「Remote Direct Memory Access Protocol（RDMA）and Direct Data Placement（DDP）の適用性」、RFC 5045、2007年10月。
[RFC6581] Kanevsky, A., Ed., Bestler, C., Ed., Sharp, R., and S. Wise, "Enhanced Remote Direct Memory Access (RDMA) Connection Establishment", RFC 6581, April 2012.
[RFC6581] Kanevsky、A.、Ed。、Bestler、C.、Ed。、Sharp、R.、and S. Wise、 "Enhanced Remote Direct Memory Access（RDMA）Connection Establishment"、RFC 6581、April 2012。
[RSOCKETS] Hefty, S., "RDMA CM - RDMA enabled Sockets library for Open Fabrics", <http://git.openfabrics.org/?p=~shefty/ librdmacm.git;a=summary>.
[RSOCKETS] Hefty、S。、「RDMA CM-RDMA enabled Sockets library for Open Fabrics」、<http://git.openfabrics.org/?p=~shefty/ librdmacm.git; a = summary>。
The authors would like to acknowledge the following individuals who provided valuable comments and suggestions.
著者は、貴重なコメントや提案を提供してくれた以下の人物に感謝したいと思います。
o David Black
o デビッドブラック
o Arkady Kanevsky
o アルカディ・カネフスキー
o Bernard Metzler
o バーナード・メッツラー
o Jim Pinkerton
o ジム・ピンカートン
o Tom Talpey
o トム・タルペイ
o Steve Wise
o スティーブ・ワイズ
o Don Wood
o ドン・ウッド
This appendix is for information only and is NOT part of the standard. It simply depicts the DDP Segment format for the various RDMA Messages.
この付録は情報提供のみを目的としており、規格の一部ではありません。さまざまなRDMAメッセージのDDPセグメント形式を示しています。
The following figure depicts an Atomic Operation Request, DDP Segment:
次の図は、アトミック操作要求、DDPセグメントを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |AOpCode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Add or Swap Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Add or Swap Mask |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compare Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compare Mask |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following figure depicts an Atomic Operation Response, DDP Segment:
次の図は、アトミック操作応答、DDPセグメントを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Atomic Operation Request) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Remote Value |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following figure depicts an Immediate Data or Immediate Data with SE, DDP Segment:
次の図は、イミディエートデータまたはSE、DDPセグメントのイミディエートデータを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Send) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Send) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Immediate Data |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
著者のアドレス
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 US Phone: 1-949-926-6941 EMail: hemal@broadcom.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine、CA 92617 US電話：1-949-926-6941メール：hemal@broadcom.com
Felix Marti Chelsio Communications, Inc. 370 San Aleso Ave. Sunnyvale, CA 94085 US Phone: 1-408-962-3600 EMail: felix@chelsio.com
Felix Marti Chelsio Communications、Inc. 370 San Aleso Ave. Sunnyvale、CA 94085 US電話：1-408-962-3600メール：felix@chelsio.com
Asgeir Eiriksson Chelsio Communications, Inc. 370 San Aleso Ave. Sunnyvale, CA 94085 US Phone: 1-408-962-3600 EMail: asgeir@chelsio.com
Asgeir Eiriksson Chelsio Communications、Inc. 370 San Aleso Ave. Sunnyvale、CA 94085 US電話：1-408-962-3600メール：asgeir@chelsio.com
Wael Noureddine Chelsio Communications, Inc. 370 San Aleso Ave. Sunnyvale, CA 94085 US Phone: 1-408-962-3600 EMail: wael@chelsio.com
Wael Noureddine Chelsio Communications、Inc. 370 San Aleso Ave. Sunnyvale、CA 94085 US電話：1-408-962-3600メール：wael@chelsio.com
Robert Sharp Intel Corporation 1300 South Mopac Expy, Mailstop: AN4-4B Austin, TX 78746 US Phone: 1-512-362-1407 EMail: robert.o.sharp@intel.com
Robert Sharp Intel Corporation 1300 South Mopac Expy、Mailstop：AN4-4B Austin、TX 78746 US Phone：1-512-362-1407 EMail：robert.o.sharp@intel.com