Internet Engineering Task Force (IETF) T. Talpey
Request for Comments: 5666 Unaffiliated
Category: Standards Track B. Callaghan
ISSN: 2070-1721 Apple
January 2010
Remote Direct Memory Access Transport for Remote Procedure Call
Abstract
抽象
This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself.
この文書では、リモートプロシージャコール（RPC）のための新しいトランスポートとしてリモートダイレクトメモリアクセス（RDMA）を提供するプロトコルについて説明します。 RPCアプリケーションへと応用RPCプロトコル、またはRPCプロトコル自体のない必要なリビジョンと最小の変化を提供しながら、結合RDMA転送は、高速ネットワーク上で効率的に、バルクデータ転送の利点を伝えます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc5666.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5666で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Abstract RDMA Requirements ......................................4
3. Protocol Outline ................................................5
3.1. Short Messages .............................................6
3.2. Data Chunks ................................................6
3.3. Flow Control ...............................................7
3.4. XDR Encoding with Chunks ...................................8
3.5. XDR Decoding with Read Chunks .............................11
3.6. XDR Decoding with Write Chunks ............................12
3.7. XDR Roundup and Chunks ....................................13
3.8. RPC Call and Reply ........................................14
3.9. Padding ...................................................17
4. RPC RDMA Message Layout ........................................18
4.1. RPC-over-RDMA Header ......................................18
4.2. RPC-over-RDMA Header Errors ...............................20
4.3. XDR Language Description ..................................20
5. Long Messages ..................................................22
5.1. Message as an RDMA Read Chunk .............................23
5.2. RDMA Write of Long Replies (Reply Chunks) .................24
6. Connection Configuration Protocol ..............................25
6.1. Initial Connection State ..................................26
6.2. Protocol Description ......................................26
7. Memory Registration Overhead ...................................28
8. Errors and Error Recovery ......................................28
9. Node Addressing ................................................28
10. RPC Binding ...................................................29
11. Security Considerations .......................................30
12. IANA Considerations ...........................................31
13. Acknowledgments ...............................................32
14. References ....................................................33
14.1. Normative References .....................................33
14.2. Informative References ...................................33
Remote Direct Memory Access (RDMA) [RFC5040, RFC5041], [IB] is a technique for efficient movement of data between end nodes, which becomes increasingly compelling over high-speed transports. By directing data into destination buffers as it is sent on a network, and placing it via direct memory access by hardware, the double benefit of faster transfers and reduced host overhead is obtained.
リモートダイレクトメモリアクセス（RDMA）[RFC5040、RFC5041]、[IB]は、高速トランスポート上ますます魅力的となるエンド・ノード間のデータの効率的な移動のための技術です。それはネットワーク上で送信される宛先バッファにデータを向けると、ハードウェアによって直接メモリアクセスを介して、それを配置することにより、高速転送および減少ホストオーバーヘッドの二重の利益が得られます。
Open Network Computing Remote Procedure Call (ONC RPC, or simply, RPC) [RFC5531] is a remote procedure call protocol that has been run over a variety of transports. Most RPC implementations today use UDP or TCP. RPC messages are defined in terms of an eXternal Data Representation (XDR) [RFC4506], which provides a canonical data representation across a variety of host architectures. An XDR data stream is conveyed differently on each type of transport. On UDP, RPC messages are encapsulated inside datagrams, while on a TCP byte stream, RPC messages are delineated by a record marking protocol. An RDMA transport also conveys RPC messages in a unique fashion that must be fully described if client and server implementations are to interoperate.
オープンネットワークコンピューティングリモートプロシージャコール（ONC RPC、または単に、RPC）[RFC5531]はトランスポートのさまざま上で実行されたリモートプロシージャコールプロトコルです。ほとんどのRPCの実装今日は、UDPまたはTCPを使用します。 RPCメッセージは、ホスト・アーキテクチャのさまざま横切るカノニカルデータ表現を提供する外部データ表現（XDR）[RFC4506]で定義されています。 XDRデータストリームは、トランスポートの種類ごとに異なって搬送されます。 TCPのバイトストリーム上で、RPCメッセージが記録マーキングプロトコルによって描写されている間、UDPで、RPCメッセージは、データグラムの中にカプセル化します。 RDMAトランスポートは、クライアントとサーバーの実装が相互運用のであれば十分に説明しなければならないユニークなファッションにRPCメッセージを伝えます。
RDMA transports present new semantics unlike the behaviors of either UDP or TCP alone. They retain message delineations like UDP while also providing a reliable, sequenced data transfer like TCP. Also, they provide the new efficient, bulk-transfer service of RDMA. RDMA transports are therefore naturally viewed as a new transport type by RPC.
RDMAは、単独のUDPまたはTCPの振る舞いとは異なり、現在、新たな意味を運びます。また、TCPのような信頼性の高い、配列決定されたデータ転送を提供しながら、彼らは、UDPのようなメッセージの描写を維持します。また、彼らは、RDMAの新しい効率的な、バルク転送サービスを提供しています。 RDMAトランスポートは、したがって、当然RPCによって新しいトランスポートタイプとして表示されます。
RDMA as a transport will benefit the performance of RPC protocols that move large "chunks" of data, since RDMA hardware excels at moving data efficiently between host memory and a high-speed network with little or no host CPU involvement. In this context, the Network File System (NFS) protocol, in all its versions [RFC1094] [RFC1813] [RFC3530] [RFC5661], is an obvious beneficiary of RDMA. A complete problem statement is discussed in [RFC5532], and related NFSv4 issues are discussed in [RFC5661]. Many other RPC-based protocols will also benefit.
RDMAハードウェアは、ホストメモリとほとんど又は全くホストCPUの関与と高速ネットワークとの間でデータを効率的に移動させるに優れているため、トランスポートとしてRDMAは、データの大規模な「チャンク」に移動RPCプロトコルの性能の利益になります。この文脈では、すべてのバージョンのネットワークファイルシステム（NFS）プロトコルは、[RFC1094]は[RFC1813]、[RFC3530]は[RFC5661]は、RDMAの明らかな受益者です。完全問題文は、[RFC5532]で議論され、関連のNFSv4問題は[RFC5661]で議論されています。他の多くのRPCベースのプロトコルにも利益になります。
Although the RDMA transport described here provides relatively transparent support for any RPC application, the proposal goes further in describing mechanisms that can optimize the use of RDMA with more active participation by the RPC application.
ここで説明したRDMA転送は、任意のRPCアプリケーションに対して比較的透明な支持体を提供するが、提案は、RPCアプリケーションによって、より積極的な参加とRDMAの使用を最適化することができるメカニズムを説明する際にさらに進みます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
An RPC transport is responsible for conveying an RPC message from a sender to a receiver. An RPC message is either an RPC call from a client to a server, or an RPC reply from the server back to the client. An RPC message contains an RPC call header followed by arguments if the message is an RPC call, or an RPC reply header followed by results if the message is an RPC reply. The call header contains a transaction ID (XID) followed by the program and procedure number as well as a security credential. An RPC reply header begins with an XID that matches that of the RPC call message, followed by a security verifier and results. All data in an RPC message is XDR encoded. For a complete description of the RPC protocol and XDR encoding, see [RFC5531] and [RFC4506].
RPCトランスポートは、送信機から受信機にRPCメッセージを搬送するための責任があります。 RPCメッセージは、クライアントからサーバーへのRPC呼び出し、またはバックサーバからクライアントへのRPC応答のいずれかです。メッセージは、RPC応答である場合、メッセージは、RPCコール、又は結果に続くRPC応答ヘッダである場合、RPCメッセージは、引数に続くRPC呼び出しヘッダを含んでいます。コールヘッダは、プログラムと手順番号ならびにセキュリティ証明書が続くトランザクションID（XID）を含みます。 RPC応答ヘッダは、セキュリティ検証し、その結果、続いてRPCコールメッセージと一致するXID、始まります。 RPCメッセージ内のすべてのデータがXDRは、符号化されています。 RPCプロトコルとXDR符号化の詳細については、[RFC5531]及び[RFC4506]を参照。
This protocol assumes the following abstract model for RDMA transports. These terms, common in the RDMA lexicon, are used in this document. A more complete glossary of RDMA terms can be found in [RFC5040].
このプロトコルは、RDMAトランスポートに対して次の抽象モデルを想定しています。これらの用語は、RDMA辞書では一般的に、この文書で使用されています。 RDMA用語のより完全な用語集は、[RFC5040]で見つけることができます。
o Registered Memory All data moved via tagged RDMA operations is resident in registered memory at its destination. This protocol assumes that each segment of registered memory MUST be identified with a steering tag of no more than 32 bits and memory addresses of up to 64 bits in length.
O登録メモリすべてのデータは、タグ付けされたRDMA動作を介して移動し、その宛先に登録メモリ内に常駐しています。このプロトコルは、登録されたメモリの各セグメントの長さは最大64ビットを超えない32ビット、メモリアドレスのステアリングタグで識別されなければならないことを前提としています。
o RDMA Send The RDMA provider supports an RDMA Send operation with completion signaled at the receiver when data is placed in a pre-posted buffer. The amount of transferred data is limited only by the size of the receiver's buffer. Sends complete at the receiver in the order they were issued at the sender.
O RDMAは、RDMAプロバイダを送信するデータが事前通知バッファに置かれたときにRDMAが受信機に完了してシグナリングオペレーションを送るサポート。転送されたデータの量だけ受信機のバッファのサイズによって制限されます。それらは、送信者に発行されたために、受信機側で完全に送信します。
o RDMA Write The RDMA provider supports an RDMA Write operation to directly place data in the receiver's buffer. An RDMA Write is initiated by the sender and completion is signaled at the sender. No completion is signaled at the receiver. The sender uses a steering tag, memory address, and length of the remote destination buffer. RDMA Writes are not necessarily ordered with respect to one another, but are ordered with respect to
O RDMAは、RDMAプロバイダが直接、受信側のバッファにデータを配置するためにRDMA書き込み操作をサポートして書きます。 RDMA書き込みは送信者によって開始され、完了は、送信者に通知されます。何の完了は、受信機で信号伝達されません。送信者は、ステアリングタグ、メモリアドレス、およびリモート宛先バッファの長さを使用します。 RDMAの書き込みは、必ずしも互いに対して順序付けされていませんが、に関して順序付けされ
RDMA Sends; a subsequent RDMA Send completion obtained at the
receiver guarantees that prior RDMA Write data has been
successfully placed in the receiver's memory.
o RDMA Read The RDMA provider supports an RDMA Read operation to directly place peer source data in the requester's buffer. An RDMA Read is initiated by the receiver and completion is signaled at the receiver. The receiver provides steering tags, memory addresses, and a length for the remote source and local destination buffers. Since the peer at the data source receives no notification of RDMA Read completion, there is an assumption that on receiving the data, the receiver will signal completion with an RDMA Send message, so that the peer can free the source buffers and the associated steering tags.
O RDMA写真ザRDMAプロバイダが直接、要求元のバッファにピア・ソース・データを配置するRDMA読み取り操作をサポートしています。 RDMA読み取りは、受信機によって開始され、完了は受信機に信号が送られます。受信機は、ステアリングタグ、メモリアドレス、およびリモートソースとローカル宛先バッファの長さを提供します。データ・ソースのピアがRDMA読み取り完了の通知を受信しないので、ピアはソースバッファと関連付けられたステアリングタグを解放することができるようにデータを受信すると、受信機は、メッセージを送信RDMAと終了を通知することを前提とされています。
This protocol is designed to be carried over all RDMA transports meeting the stated requirements. This protocol conveys to the RPC peer information sufficient for that RPC peer to direct an RDMA layer to perform transfers containing RPC data and to communicate their result(s). For example, it is readily carried over RDMA transports such as Internet Wide Area RDMA Protocol (iWARP) [RFC5040, RFC5041], or InfiniBand [IB].
このプロトコルは、すべてのRDMAは述べた要件を満たすトランスポート上で実行されるように設計されています。このプロトコルは、RPCデータを含む転送を実行し、その結果（複数可）を通信するためにRDMA層を指示することRPCピアに十分なRPCピア情報を伝えます。例えば、それは容易にRDMAを介して搬送され、インターネットワイドエリアRDMAプロトコル（iWARPの）[RFC5040、RFC5041]、またはインフィニバンド[IB]と搬送します。
An RPC message can be conveyed in identical fashion, whether it is a call or reply message. In each case, the transmission of the message proper is preceded by transmission of a transport-specific header for use by RPC-over-RDMA transports. This header is analogous to the record marking used for RPC over TCP, but is more extensive, since RDMA transports support several modes of data transfer; it is important to allow the upper-layer protocol to specify the most efficient mode for each of the segments in a message. Multiple segments of a message may thereby be transferred in different ways to different remote memory destinations.
RPCメッセージは、コール又は応答メッセージであるか否かを、同一の方法で搬送することができます。それぞれの場合において、適切なメッセージの送信は、RPCオーバーRDMAトランスポートによって使用するためのトランスポート固有のヘッダの送信によって先行されます。このヘッダは、TCP上のRPCに使用されるマーキングレコードに類似しているが、RDMAデータ転送のいくつかのモードをサポートして搬送するので、より広範囲です。上位層プロトコルは、メッセージ内のセグメントの各々のための最も効率的なモードを指定できるようにすることが重要です。メッセージの複数のセグメントは、それによって異なるリモートメモリ宛先に異なる方法で転送することができます。
All transfers of a call or reply begin with an RDMA Send that transfers at least the RPC-over-RDMA header, usually with the call or reply message appended, or at least some part thereof. Because the size of what may be transmitted via RDMA Send is limited by the size of the receiver's pre-posted buffer, the RPC-over-RDMA transport provides a number of methods to reduce the amount transferred by means of the RDMA Send, when necessary, by transferring various parts of the message using RDMA Read and RDMA Write.
RDMAで始まるコールまたは応答の全ての転送は、通常のコールと、その少なくとも転送RPCオーバーRDMAのヘッダを送信または添付メッセージを返信、または少なくともその一部。 RDMAの送信を介して送信することができるもののサイズは、受信機の事前通知バッファのサイズによって制限されるため、RPCオーバーRDMA転送は、必要なときに、送信RDMAにより転送量を減少させるために多数の方法を提供します、RDMA ReadとRDMA書き込みを使用して、メッセージのさまざまな部分を転送することもできます。
RPC-over-RDMA framing replaces all other RPC framing (such as TCP record marking) when used atop an RPC/RDMA association, even though the underlying RDMA protocol may itself be layered atop a protocol with a defined RPC framing (such as TCP). It is however possible for RPC/RDMA to be dynamically enabled, in the course of negotiating the use of RDMA via an upper-layer exchange. Because RPC framing delimits an entire RPC request or reply, the resulting shift in framing must occur between distinct RPC messages, and in concert with the transport.
RPCオーバーRDMAフレーミングは、基礎となるRDMAプロトコルは、それ自体が（例えばTCPのような）定義RPCフレーミングとプロトコルの上に積層することができるにもかかわらず、RPC / RDMAアソシエーションの上に使用される（例えばマーキングTCPレコードのような）他のすべてのRPCフレーミングを置き換え。 RPC / RDMAを動的上層交換を介してRDMAの使用を交渉する過程で、有効にするためには可能です。 RPCフレーミング全体RPC要求または応答を画定するので、フレーミングで得られたシフトは、異なるRPCメッセージ間、及び搬送と協調して行われなければなりません。
Many RPC messages are quite short. For example, the NFS version 3 GETATTR request, is only 56 bytes: 20 bytes of RPC header, plus a 32-byte file handle argument and 4 bytes of length. The reply to this common request is about 100 bytes.
多くのRPCメッセージは非常に短いです。 RPCヘッダの20バイト、プラス32バイトのファイルハンドルを引数と長さの4バイト：例えば、NFSバージョン3 GETATTR要求は、わずか56バイトです。この共通の要求に対する応答は、約100バイトです。
There is no benefit in transferring such small messages with an RDMA Read or Write operation. The overhead in transferring steering tags and memory addresses is justified only by large transfers. The critical message size that justifies RDMA transfer will vary depending on the RDMA implementation and network, but is typically of the order of a few kilobytes. It is appropriate to transfer a short message with an RDMA Send to a pre-posted buffer. The RPC-over-RDMA header with the short message (call or reply) immediately following is transferred using a single RDMA Send operation.
RDMA読み取りまたは書き込み操作で、このような小さなメッセージを転送する際の利点はありません。ステアリングタグとメモリアドレスを転送する際にオーバーヘッドは唯一の大規模な移転によって正当化されます。 RDMA転送を正当化する重要なメッセージのサイズは、RDMAの実装やネットワークに依存して変化するが、典型的には数キロバイトのオーダーであるだろう。事前通知バッファに送信RDMAでショートメッセージを転送することが適切です。 RPCオーバーRDMAヘッダショートメッセージを（電話または応答）直ちに単一RDMAオペレーションを送るを使用して転送される以下。
Short RPC messages over an RDMA transport:
RDMAトランスポート上のショートRPCメッセージ：
RPC Client RPC Server
| RPC Call |
Send | ------------------------------> |
| |
| RPC Reply |
| <------------------------------ | Send
Some protocols, like NFS, have RPC procedures that can transfer very large chunks of data in the RPC call or reply and would cause the maximum send size to be exceeded if one tried to transfer them as part of the RDMA Send. These large chunks typically range from a kilobyte to a megabyte or more. An RDMA transport can transfer large chunks of data more efficiently via the direct placement of an RDMA Read or RDMA Write operation. Using direct placement instead of inline transfer not only avoids expensive data copies, but provides correct data alignment at the destination.
NFSのようないくつかのプロトコルは、RPCコールでデータの非常に大きなチャンクを転送したり、返信、もう1つはRDMAの送信の一部としてそれらを転送しようとした場合、最大送信サイズを超えたことが原因となることができますRPCの手順を持っています。これらの大きな塊は、通常キロバイトからメガバイト以上に及びます。 RDMA輸送は、RDMA読み取りまたはRDMA書き込み操作の直接配置を経由して、より効率的にデータの大きなチャンクを転送することができます。直接配置の代わりにインライン転送を使用することだけでなく、高価なデータ・コピーを回避するが、先に正しいデータ整列を提供します。
It is critical to provide RDMA Send flow control for an RDMA connection. RDMA receive operations will fail if a pre-posted receive buffer is not available to accept an incoming RDMA Send, and repeated occurrences of such errors can be fatal to the connection. This is a departure from conventional TCP/IP networking where buffers are allocated dynamically on an as-needed basis, and where pre-posting is not required.
RDMA接続のためのRDMA送信フロー制御を提供することが重要です。 RDMAは、事前に掲示受信バッファが入ってくるRDMAを送る受け入れるように利用できない場合の操作は失敗します受信し、このようなエラーの繰り返し出現は、接続に致命的なことができます。これは、事前に掲示が必要とされていない従来のTCP / IPバッファは、必要に応じて動的に割り当てられ、ネットワーキング、およびからの出発です。
It is not practical to provide for fixed credit limits at the RPC server. Fixed limits scale poorly, since posted buffers are dedicated to the associated connection until consumed by receive operations. Additionally, for protocol correctness, the RPC server must always be able to reply to client requests, whether or not new buffers have been posted to accept future receives. (Note that the RPC server may in fact be a client at some other layer. For example, NFSv4 callbacks are processed by the NFSv4 client, acting as an RPC server. The credit discussions apply equally in either case.)
RPCサーバーでの固定信用限度を提供するために実用的ではありません。受信動作によって消費されるまで掲載バッファが関連する接続専用されているので、固定限界は、不十分なスケール。また、プロトコルの正しさのために、RPCサーバーは、常に新しいバッファは未来が受け取る受け入れるように掲載されているかどうかにかかわらず、クライアントの要求に答えることができなければなりません。 （RPCサーバーが実際にいくつかの他の層でのクライアントであってもよい。例えば、NFSv4のコールバックは、RPCサーバーとして動作し、NFSv4クライアントによって処理されている。クレジット議論はいずれの場合にも同様に適用されます。）
Flow control for RDMA Send operations is implemented as a simple request/grant protocol in the RPC-over-RDMA header associated with each RPC message. The RPC-over-RDMA header for RPC call messages contains a requested credit value for the RPC server, which MAY be dynamically adjusted by the caller to match its expected needs. The RPC-over-RDMA header for the RPC reply messages provides the granted result, which MAY have any value except it MUST NOT be zero when no in-progress operations are present at the server, since such a value would result in deadlock. The value MAY be adjusted up or down at each opportunity to match the server's needs or policies.
RDMAのためのフロー制御は、各RPCメッセージに関連付けられたRPCオーバーRDMAヘッダに単純な要求/許可プロトコルとして実装されている動作を送ります。 RPC呼び出しメッセージのRPCオーバーRDMAヘッダが動的に期待のニーズに合うように、発信者によって調整することができるRPCサーバーのための要求されたクレジット値が含まれています。 RPC応答メッセージのRPCオーバーRDMAヘッダには、進行中の操作はサーバに存在しない場合、そのような値は、デッドロックをもたらすため、それは、ゼロであってはなりません以外の任意の値を有することができる許可された結果を提供します。値は、サーバのニーズや政策と一致するように、それぞれの機会に上下に調整することができます。
The RPC client MUST NOT send unacknowledged requests in excess of this granted RPC server credit limit. If the limit is exceeded, the RDMA layer may signal an error, possibly terminating the connection. Even if an error does not occur, it is OPTIONAL that the server handle the excess request(s), and it MAY return an RPC error to the client. Also note that the never-zero requirement implies that an RPC server MUST always provide at least one credit to each connected RPC client from which no requests are outstanding. The client would deadlock otherwise, unable to send another request.
RPCクライアントは、この許可されたRPCサーバーの利用限度額を超える未確認のリクエストを送ってはいけません。限界を超えた場合、RDMA層は、おそらく接続を終了、エラーを通知してもよいです。エラーが発生していない場合でも、サーバは過剰要求（複数可）を扱うことをオプションであり、それがクライアントにRPCエラーを返すことがあります。また、決してゼロ要件は、RPCサーバーは、常に何の要求は未解決ではない、そこから接続されている各RPCクライアントに対して少なくとも1枚のクレジットを提供しなければならないことを意味することに注意してください。クライアントが別の要求を送信することができない、それ以外の場合はデッドロックです。
While RPC calls complete in any order, the current flow control limit at the RPC server is known to the RPC client from the Send ordering properties. It is always the most recent server-granted credit value minus the number of requests in flight.
RPCは任意の順序で完全呼び出している間、RPCサーバーでの現在のフロー制御の制限は、プロパティを注文sendからRPCクライアントに知られています。それは、常に最新のサーバー・付与されたクレジット値マイナス飛行中の要求の数です。
Certain RDMA implementations may impose additional flow control restrictions, such as limits on RDMA Read operations in progress at the responder. Because these operations are outside the scope of this protocol, they are not addressed and SHOULD be provided for by other layers. For example, a simple upper-layer RPC consumer might perform single-issue RDMA Read requests, while a more sophisticated, multithreaded RPC consumer might implement its own First In, First Out (FIFO) queue of such operations. For further discussion of possible protocol implementations capable of negotiating these values, see Section 6 "Connection Configuration Protocol" of this document, or [RFC5661].
特定のRDMA実装は、レスポンダで進行中のRDMA読み取り操作上の制限などの追加のフロー制御の制約を課すことができます。これらの操作は、このプロトコルの範囲外であるため、それらが対処されていない他の層によって提供されるべきです。たとえば、単純な上位層のRPCの消費者は、単一の問題RDMA読み取り要求を実行する可能性がより洗練された一方で、マルチスレッドRPCの消費者は、このような操作の独自のファーストイン、ファーストアウト（FIFO）キューを実装するかもしれません。これらの値を交渉することができる可能なプロトコル実装の詳細な説明については、本文書、または[RFC5661]のセクション6「接続構成プロトコル」を参照。
The data comprising an RPC call or reply message is marshaled or serialized into a contiguous stream by an XDR routine. XDR data types such as integers, strings, arrays, and linked lists are commonly implemented over two very simple functions that encode either an XDR data unit (32 bits) or an array of bytes.
RPCコールまたは応答メッセージを含むデータをマーシャリングまたはXDRルーチンによって連続ストリームにシリアル化されます。例えば、整数、ストリング、アレイ、及びリンクされたリストのようなXDRデータ型は、一般XDRデータ単位（32ビット）またはバイトの配列のいずれかをコードする2つの非常に単純な関数の上に実装されています。
Normally, the separate data items in an RPC call or reply are encoded as a contiguous sequence of bytes for network transmission over UDP or TCP. However, in the case of an RDMA transport, local routines such as XDR encode can determine that (for instance) an opaque byte array is large enough to be more efficiently moved via an RDMA data transfer operation like RDMA Read or RDMA Write.
通常、RPCコールまたは応答における別個のデータ項目は、UDPまたはTCP上のネットワーク伝送のためのバイトの連続するシーケンスとして符号化されます。しかし、RDMA転送の場合には、そのようなXDRエンコードなどのローカルルーチンは、不透明なバイト配列をより効率的にRDMA読み取り又はRDMA書き込みのようなRDMAデータ転送動作を介して移動させることに十分な大きさ（例えば）それを決定することができます。
Semantically speaking, the protocol has no restriction regarding data types that may or may not be represented by a read or write chunk. In practice however, efficiency considerations lead to the conclusion that certain data types are not generally "chunkable". Typically, only those opaque and aggregate data types that may attain substantial size are considered to be eligible. With today's hardware, this size may be a kilobyte or more. However, any object MAY be chosen for chunking in any given message.
意味論的に言えば、プロトコルは、または読み取りまたは書き込みチャンクによって表されなくてもよいデータ・タイプに関する制限がありません。しかし実際には、効率の考慮事項は、特定のデータ・タイプは、一般的に「chunkable」ではないという結論につながります。典型的には、かなりの大きさを達成することができるのみ不透明と集約データタイプは適格であると考えられます。今日のハードウェアでは、このサイズはキロバイト以上であってもよいです。しかし、任意のオブジェクトは、任意の所与のメッセージにチャンクのために選択することができます。
The eligibility of XDR data items to be candidates for being moved as data chunks (as opposed to being marshaled inline) is not specified by the RPC-over-RDMA protocol. Chunk eligibility criteria MUST be determined by each upper-layer in order to provide for an interoperable specification. One such example with rationale, for the NFS protocol family, is provided in [RFC5667].
（インラインマーシャリングされるのとは対照的に）データチャンクとして移動されるための候補となるXDRデータ項目の適格性は、RPCオーバーRDMAプロトコルによって指定されていません。チャンク適格基準は、相互運用可能な仕様を提供するために、各上位層によって決定されなければなりません。理論的根拠を有するもの、例えば、NFSプロトコルファミリのために、[RFC5667]に提供されます。
The interface by which an upper-layer implementation communicates the eligibility of a data item locally to RPC for chunking is out of scope for this specification. In many implementations, it is possible to implement a transparent RPC chunking facility. However, such implementations may lead to inefficiencies, either because they require the RPC layer to perform expensive registration and de-registration of memory "on the fly", or they may require using RDMA chunks in reply messages, along with the resulting additional handshaking with the RPC-over-RDMA peer. However, these issues are internal and generally confined to the local interface between RPC and its upper layers, one in which implementations are free to innovate. The only requirement is that the resulting RPC RDMA protocol sent to the peer is valid for the upper layer. See, for example, [RFC5667].
上層実装はチャンクのためのRPCにローカルデータ項目の適格性を通信することにより、インターフェースは、本明細書の範囲外です。多くの実装では、透明RPCのチャンキング機能を実装することが可能です。しかしながら、これらは高価で、登録とメモリの登録解除を実行するためにRPC層を必要とするので、そのような実装は、「オンザフライ」のいずれか、非効率につながる可能性があり、またはそれらは、応答メッセージにRDMAチャンクを使用して必要とするかもしれない、との結果として生じる付加的なハンドシェイクと一緒RPCオーバーRDMAピア。しかしながら、これらの問題は内部であり、一般にRPCとその上位層との間のローカルインタフェース、実装が革新して自由にされたものに限られました。唯一の要件は、ピアに送信され、得られたRPCのRDMAプロトコルは、上位層のために有効であることです。例えば、[RFC5667]を参照してください。
When sending any message (request or reply) that contains an eligible large data chunk, the XDR encoding routine avoids moving the data into the XDR stream. Instead, it does not encode the data portion, but records the address and size of each chunk in a separate "read chunk list" encoded within RPC RDMA transport-specific headers. Such chunks will be transferred via RDMA Read operations initiated by the receiver.
適格大きなデータチャンクを含む任意のメッセージ（要求または応答）を送信するときに、XDR符号化ルーチンは、XDRストリームにデータを移動させることが回避されます。代わりに、データ部分をコードするが、RPC RDMA転送固有のヘッダ内に符号化された別々の「読み取りチャンクリスト」内の各チャンクのアドレスとサイズを記録しません。このような塊は、受信機によって開始さRDMA読み取り操作を介して転送されます。
When the read chunks are to be moved via RDMA, the memory for each chunk is registered. This registration may take place within XDR itself, providing for full transparency to upper layers, or it may be performed by any other specific local implementation.
読み出しチャンクがRDMAを介して移動する場合に、各チャンクのためのメモリが登録されています。この登録は、上位層への完全な透明性を提供する、XDR自体の中で行うことができる、または、任意の他の特定のローカルの実装によって実行されてもよいです。
Additionally, when making an RPC call that can result in bulk data transferred in the reply, write chunks MAY be provided to accept the data directly via RDMA Write. These write chunks will therefore be pre-filled by the RPC server prior to responding, and XDR decode of the data at the client will not be required. These chunks undergo a similar registration and advertisement via "write chunk lists" built as a part of XDR encoding.
返事で転送バルクデータをもたらすことがRPCコールを行うときにまた、チャンクがRDMA書き込みを経由して直接データを受け入れるために設けられてもよい書きます。これらの書き込みチャンクは、したがって、前の応答にRPCサーバーによってあらかじめ入力され、クライアントでのデータのXDRデコードが必要とされることはありません。これらのチャンクはXDRエンコーディングの一環として建設され、「書き込みチャンクリスト」を介して同様の登録と広告を受けます。
Some RPC client implementations are not able to determine where an RPC call's results reside during the "encode" phase. This makes it difficult or impossible for the RPC client layer to encode the write chunk list at the time of building the request. In this case, it is difficult for the RPC implementation to provide transparency to the RPC consumer, which may require recoding to provide result information at this earlier stage.
いくつかのRPCクライアント実装は、RPC呼び出しの結果は「エンコード」フェーズの間に存在する場所を決定することができません。これは、要求を構築する時に書き込みチャンクリストをエンコードするRPCクライアント層のためにそれが困難または不可能になります。この場合には、RPC実装がこの早い段階で結果情報を提供するために、再符号化が必要かもしれない、RPCの消費者に透明性を提供することは困難です。
Therefore, if the RPC client does not make a write chunk list available to receive the result, then the RPC server MAY return data inline in the reply, or if the upper-layer specification permits, it MAY be returned via a read chunk list. It is NOT RECOMMENDED that upper-layer RPC client protocol specifications omit write chunk lists for eligible replies, due to the lower performance of the additional handshaking to perform data transfer, and the requirement that the RPC server must expose (and preserve) the reply data for a period of time. In the absence of a server-provided read chunk list in the reply, if the encoded reply overflows the posted receive buffer, the RPC will fail with an RDMA transport error.
したがって、RPCクライアントが結果を受信する書き込みチャンクリストを利用できるようにしていない場合、は、RPCサーバーは応答でデータをインラインで返してもよい、または上位層の仕様が許すならば、それは読み取りチャンクリストを経由して返されることがあります。上位層のRPCクライアントプロトコルの仕様が原因RPCサーバーが応答データを公開（および保存）しなければならないデータ転送を実行するための追加的なハンドシェイク、および要件の下パフォーマンスに、適格な回答の書き込みチャンクリストを省略することはお勧めできません一定の期間のため。符号化された応答が受信通知バッファをオーバーフローした場合、応答でサーバが提供するリードチャンクリストの非存在下で、RPCは、RDMA転送エラーで失敗します。
When any data within a message is provided via either read or write chunks, the chunk itself refers only to the data portion of the XDR stream element. In particular, for counted fields (e.g., a "<>" encoding) the byte count that is encoded as part of the field remains in the XDR stream, and is also encoded in the chunk list. The data portion is however elided from the encoded XDR stream, and is transferred as part of chunk list processing. It is important to maintain upper-layer implementation compatibility -- both the count and the data must be transferred as part of the logical XDR stream. While the chunk list processing results in the data being available to the upper-layer peer for XDR decoding, the length present in the chunk list entries is not. Any byte count in the XDR stream MUST match the sum of the byte counts present in the corresponding read or write chunk list. If they do not agree, an RPC protocol encoding error results.
メッセージ内の任意のデータの読み出しまたは書き込みのいずれかのチャンクを介して提供される場合、チャンク自体は、XDRストリーム要素のデータ部分を指します。具体的には、カウントフィールドに対して（例えば、A「<>」符号）フィールドの一部として符号化されるバイト数は、XDRストリームのままであり、また、チャンクのリストで符号化されます。データ部分は、しかし、符号化されたXDRストリームから省略され、チャンクリスト処理の一部として転送されます。上位層の実装との互換性を維持することが重要である - 数とデータの両方が論理的なXDRストリームの一部として転送する必要があります。データにおけるチャンクのリスト処理結果がXDR復号化のための上層ピアに利用可能でありながら、チャンクリストエントリ内に存在する長さではありません。 XDRストリーム内の任意のバイト数が、対応する読み取りまたは書き込みチャンクリストに存在するバイト数の合計と一致しなければなりません。彼らは同意しない場合は、RPCプロトコルは、エラー結果を符号化します。
The following items are contained in a chunk list entry.
以下の項目がチャンクリストエントリに含まれています。
Handle Steering tag or handle obtained when the chunk memory is registered for RDMA.
チャンクメモリはRDMAのために登録されたときに得られたステアリングタグを処理または扱います。
Length The length of the chunk in bytes.
バイト単位の長さのチャンクの長さ。
Offset The offset or beginning memory address of the chunk. In order to support the widest array of RDMA implementations, as well as the most general steering tag scheme, this field is unconditionally included in each chunk list entry.
チャンクのオフセットまたは開始メモリアドレスをオフセット。 RDMA実装の広い配列、ならびに最も一般的なステアリング・タグ・スキームをサポートするために、このフィールドは無条件に各チャンクリストエントリに含まれています。
While zero-based offset schemes are available in many RDMA
implementations, their use by RPC requires individual
registration of each read or write chunk. On many such
implementations, this can be a significant overhead. By
providing an offset in each chunk, many pre-registration or
region-based registrations can be readily supported, and by
using a single, universal chunk representation, the RPC RDMA
protocol implementation is simplified to its most general form.
Position For data that is to be encoded, the position in the XDR stream where the chunk would normally reside. Note that the chunk therefore inserts its data into the XDR stream at this position, but its transfer is no longer "inline". Also note therefore that all chunks belonging to a single RPC argument or result will have the same position. For data that is to be decoded, no position is used.
符号化されるデータのための位置、チャンクが通常存在するであろうXDRストリーム内の位置。チャンクは、従って、この位置でXDRストリームにそのデータを挿入していないが、その転写がもはや「インライン」であることに留意されたいです。また、単一のRPC引数または結果に属するすべてのチャンクが同じ位置になりますことは注意してください。復号化されるデータのために、何の位置が使用されません。
When XDR marshaling is complete, the chunk list is XDR encoded, then sent to the receiver prepended to the RPC message. Any source data for a read chunk, or the destination of a write chunk, remain behind in the sender's registered memory, and their actual payload is not marshaled into the request or reply.
XDRマーシャリングが完了すると、チャンクリストはXDR符号化され、その後、RPCメッセージの先頭に追加受信機に送信されます。読み取りチャンク、または書き込みチャンクの宛先のための任意のソースデータは、送信者の登録メモリ内に残る、そして彼らの実際のペイロードは、要求または応答にマーシャリングされていません。
+----------------+----------------+-------------
| RPC-over-RDMA | |
| header w/ | RPC Header | Non-chunk args/results
| chunks | |
+----------------+----------------+-------------
Read chunk lists and write chunk lists are structured somewhat differently. This is due to the different usage -- read chunks are decoded and indexed by their argument's or result's position in the XDR data stream; their size is always known. Write chunks, on the other hand, are used only for results, and have neither a preassigned offset in the XDR stream nor a size until the results are produced, since the buffers may be only partially filled, or may not be used for results at all. Their presence in the XDR stream is therefore not known until the reply is processed. The mapping of write chunks onto designated NFS procedures and their results is described in [RFC5667].
チャンクリストを読み書きチャンクリストは多少異なる構成されています。これは、さまざまな使用によるものである - チャンクが復号化され、その引数のやXDRデータ・ストリームにおける結果の位置によってインデックス付けされて読ま。その大きさは常に知られています。チャンクを書く一方で、結果だけのために使用され、バッファは部分的にしか充填されてもよい、またはでの結果のために使用することができないので、結果は、生成されるまで、事前に割り当てられXDRストリームやサイズでオフセットなかったどちらもすべて。応答が処理されるまでXDRストリームにおけるそれらの存在は、したがって、知られていません。指定されたNFS手順とその結果への書き込みチャンクのマッピングは[RFC5667]に記載されています。
Therefore, read chunks are encoded into a read chunk list as a single array, with each entry tagged by its (known) size and its argument's or result's position in the XDR stream. Write chunks are encoded as a list of arrays of RDMA buffers, with each list element (an array) providing buffers for a separate result. Individual write chunk list elements MAY thereby result in being partially or fully filled, or in fact not being filled at all. Unused write chunks, or unused bytes in write chunk buffer lists, are not returned as results, and their memory is returned to the upper layer as part of RPC completion. However, the RPC layer MUST NOT assume that the buffers have not been modified.
したがって、読み取りチャンクは（既知の）サイズとXDRストリームにおける引数のまたは結果の位置によってタグ付けされた各エントリに、単一のアレイとしてリードチャンクリストに符号化されます。書き込みチャンクは別の結果のためのバッファを提供する各リスト要素（アレイ）と、RDMAバッファの配列のリストとしてエンコードされます。個々の書き込みチャンクリストの要素は、それによって部分的または完全に充填されているになることがあり、あるいは実際にはまったく満たされていません。未使用の書き込みチャンク、または書き込みチャンクバッファリスト内の未使用バイトは、結果として返されていない、およびそれらのメモリは、RPC完了の一部として上位層に戻されます。しかし、RPC層は、バッファが変更されていないと仮定してはいけません。
The XDR decode process moves data from an XDR stream into a data structure provided by the RPC client or server application. Where elements of the destination data structure are buffers or strings, the RPC application can either pre-allocate storage to receive the data or leave the string or buffer fields null and allow the XDR decode stage of RPC processing to automatically allocate storage of sufficient size.
XDRデコードプロセスは、RPCクライアントまたはサーバ・アプリケーションによって提供されるデータ構造にXDRストリームからデータを移動させます。宛先データ構造の要素は、緩衝液または文字列である場合、RPCアプリケーションは、いずれかのデータを受信またはヌル文字列またはバッファのフィールドを残してRPC処理のXDRデコードステージが自動的に十分なサイズのストレージを割り当てることができるように記憶域を予め割り当てることができます。
When decoding a message from an RDMA transport, the receiver first XDR decodes the chunk lists from the RPC-over-RDMA header, then proceeds to decode the body of the RPC message (arguments or results). Whenever the XDR offset in the decode stream matches that of a chunk in the read chunk list, the XDR routine initiates an RDMA Read to bring over the chunk data into locally registered memory for the destination buffer.
RDMA転送からのメッセージを復号する際、レシーバ第XDRは、RPCオーバーRDMAヘッダからチャンクリストをデコードし、その後、RPCメッセージ（引数又は結果）の本体をデコードに進みます。デコードストリームにオフセットXDRが読み取りチャンクリストにチャンクのそれと一致するたびに、XDRルーチンは、宛先バッファにローカルに登録メモリにチャンクデータの上に持ってRDMA読み取りを開始します。
When processing an RPC request, the RPC receiver (RPC server) acknowledges its completion of use of the source buffers by simply replying to the RPC sender (client), and the peer may then free all source buffers advertised by the request.
RPC要求を処理するときに、RPCレシーバ（RPCサーバー）は、単にRPC送信者（クライアント）に応答して、ソースバッファの使用のその完了を認識し、ピアは、その後、自由全てのソースバッファが要求によって通知してもよいです。
When processing an RPC reply, after completing such a transfer, the RPC receiver (client) MUST issue an RDMA_DONE message (described in Section 3.8) to notify the peer (server) that the source buffers can be freed.
RPC応答を処理するとき、そのような転送が完了した後、RPCの受信機（クライアント）は、ソースバッファが解放されることができるピア（サーバ）を通知する（セクション3.8を参照）RDMA_DONEメッセージを発行しなければなりません。
The read chunk list is constructed and used entirely within the RPC/XDR layer. Other than specifying the minimum chunk size, the management of the read chunk list is automatic and transparent to an RPC application.
読み取りチャンクのリストを構築し、RPC / XDR層内に完全に使用されています。最小チャンクサイズを指定する以外に、読み出しチャンクリストの管理は、RPCアプリケーションに自動的かつ透過的です。
When a write chunk list is provided for the results of the RPC call, the RPC server MUST provide any corresponding data via RDMA Write to the memory referenced in the chunk list entries. The RPC reply conveys this by returning the write chunk list to the client with the lengths rewritten to match the actual transfer. The XDR decode of the reply therefore performs no local data transfer but merely returns the length obtained from the reply.
書き込みチャンクリストはRPC呼び出しの結果のために提供されている場合、RPCサーバーは、チャンクリストエントリで参照されるメモリにRDMA書き込みを経由して任意の対応するデータを提供しなければなりません。 RPC応答は、実際の転送に一致するように書き換えられた長さのクライアントへの書き込みチャンクのリストを返すことによって、これを伝えます。応答のXDRデコードは、従って、ローカルデータ転送を行わず単に応答から得られた長さを返します。
Each decoded result consumes one entry in the write chunk list, which in turn consists of an array of RDMA segments. The length is therefore the sum of all returned lengths in all segments comprising the corresponding list entry. As each list entry is decoded, the entire entry is consumed.
各デコード結果は、順番にRDMAセグメントのアレイからなる書き込みチャンクのリスト内の1つのエントリを消費します。長さは、従って、全ての合計は、対応するリストのエントリを含むすべてのセグメントの長さが返されます。各リストのエントリがデコードされると、エントリ全体が消費されます。
The write chunk list is constructed and used by the RPC application. The RPC/XDR layer simply conveys the list between client and server and initiates the RDMA Writes back to the client. The mapping of write chunk list entries to procedure arguments MUST be determined for each protocol. An example of a mapping is described in [RFC5667].
書き込みチャンクリストを構築し、RPCアプリケーションで使用されています。 RPC / XDR層は、単純に、クライアントとサーバ間のリストを伝えると、RDMAは、クライアントに戻って書き込みを開始します。プロシージャ引数に書き込みチャンクリストエントリのマッピングは、各プロトコルのために決定されなければなりません。マッピングの例は、[RFC5667]に記載されています。
The XDR protocol requires 4-byte alignment of each new encoded element in any XDR stream. This requirement is for efficiency and ease of decode/unmarshaling at the receiver -- if the XDR stream buffer begins on a native machine boundary, then the XDR elements will lie on similarly predictable offsets in memory.
XDRプロトコルは、任意のXDRストリーム内の各新規の符号化要素の4バイトアライメントを必要とします。この要件は、受信機でアンマーシャリング/デコードの効率および容易さのためである - XDRストリームバッファは、ネイティブマシン境界で始まる場合、XDR要素は、メモリに同様に予測可能なオフセットにあるだろう。
Within XDR, when non-4-byte encodes (such as an odd-length string or bulk data) are marshaled, their length is encoded literally, while their data is padded to begin the next element at a 4-byte boundary in the XDR stream. For TCP or RDMA inline encoding, this minimal overhead is required because the transport-specific framing relies on the fact that the relative offset of the elements in the XDR stream from the start of the message determines the XDR position during decode.
それらのデータは、XDRで4バイト境界で次の要素を開始するために埋め込まれつつXDR内、（例えば、奇数長の文字列またはバルクデータのような）非4バイトのエンコードをマーシャリングされたとき、それらの長さは、文字通り符号化されますストリーム。トランスポート固有のフレーミングがメッセージの開始からXDRストリーム内の要素の相対オフセットは、デコード中XDR位置を決定するという事実に依存しているので、TCP又はRDMAインライン符号化のために、この最小限のオーバーヘッドが必要となります。
On the other hand, RPC/RDMA Read chunks carry the XDR position of each chunked element and length of the Chunk segment, and can be placed by the receiver exactly where they belong in the receiver's memory without regard to the alignment of their position in the XDR stream. Since any rounded-up data is not actually part of the upper layer's message, the receiver will not reference it, and there is no reason to set it to any particular value in the receiver's memory.
一方、RPC / RDMA読み取りチャンクは各チャンク要素およびチャンクセグメントの長さのXDR位置を運び、そしてにおけるそれらの位置の配向に関係なく、彼らは、受信機のメモリに属する正確に受信機によって配置することができますXDRストリーム。任意切り上げデータが実際に上位レイヤのメッセージの一部ではないので、受信機はそれを参照しないであろう、そして受信機のメモリ内の任意の特定の値に設定する理由はありません。
When roundup is present at the end of a sequence of chunks, the length of the sequence will terminate it at a non-4-byte XDR position. When the receiver proceeds to decode the remaining part of the XDR stream, it inspects the XDR position indicated by the next chunk. Because this position will not match (else roundup would not have occurred), the receiver decoding will fall back to inspecting the remaining inline portion. If in turn, no data remains to be decoded from the inline portion, then the receiver MUST conclude that roundup is present, and therefore it advances the XDR decode position to that indicated by the next chunk (if any). In this way, roundup is passed without ever actually transferring additional XDR bytes.
ラウンドアップはチャンクの配列の末端に存在する場合、配列の長さは、非4バイトXDR位置でそれを終了します。受信機は、XDRストリームの残りの部分を復号するために進んだ場合、それは次のチャンクで示さXDR位置を検査します。この位置は、（他のラウンドアップが発生していない）と一致しないので、受信機の復号は、残りのインライン部分の検査にフォールバックします。次に、データがインライン部分から復号されないままでない場合、受信機は、ラウンドアップが存在していると結論しなければならないので、それが次のチャンク（もしあれば）で示されるものとXDRデコード位置を進めます。このように、ラウンドアップは、これまで実際に追加XDRバイトを転送せずに渡されます。
Some protocol operations over RPC/RDMA, for instance NFS writes of data encountered at the end of a file or in direct I/O situations, commonly yield these roundups within RDMA Read Chunks. Because any roundup bytes are not actually present in the data buffers being written, memory for these bytes would come from noncontiguous buffers, either as an additional memory registration segment or as an additional Chunk. The overhead of these operations can be significant to both the sender to marshal them and even higher to the receiver to which to transfer them. Senders SHOULD therefore avoid encoding individual RDMA Read Chunks for roundup whenever possible. It is acceptable, but not necessary, to include roundup data in an existing RDMA Read Chunk, but only if it is already present in the XDR stream to carry upper-layer data.
RPC / RDMAを超えるいくつかのプロトコル動作は、例えばNFSは、ファイルの末尾またはダイレクトI / Oの状況に遭遇したデータの書き込みを行う、一般的にRDMA読むチャンク内でこれらのroundupsをもたらします。任意のラウンドアップバイトが実際に書き込まれるデータバッファに存在しないため、これらのバイトのためのメモリは、追加のメモリ登録セグメントとして、または追加のチャンクのいずれかと、非連続バッファから来ます。これらの操作のオーバーヘッドは、受信機に転送するためにそれらをマーシャリングするために、送信者とさらに高いの両方に重要になります。送信者は、したがって、可能な限り検挙のために、個々のRDMA読み取りチャンクをコードすることは避けてください。これは、既存のRDMA読み取りチャンクにまとめたデータを含むように、必要に許容される、ではないが、それは、上位層データを搬送するためにXDRストリーム内に既に存在する場合にのみ。
Note that there is no exposure of additional data at the sender due to eliding roundup data from the XDR stream, since any additional sender buffers are never exposed to the peer. The data is literally not there to be transferred.
追加の送信元バッファはピアに公開されることはありませんので、原因XDRストリームから検挙データをelidingに送信者の追加データのない露出は、存在しないことに注意してください。データが転送されるが、文字通りではありません。
For RDMA Write Chunks, a simpler encoding method applies. Again, roundup bytes are not transferred, instead the chunk length sent to the receiver in the reply is simply increased to include any roundup. Because of the requirement that the RDMA Write Chunks are filled sequentially without gaps, this situation can only occur on the final chunk receiving data. Therefore, there is no opportunity for roundup data to insert misalignment or positional gaps into the XDR stream.
RDMA書き込みチャンクの場合は、単純な符号化方法が適用されます。再び、ラウンドアップバイトが転送されず、代わりに応答において受信機に送信されたチャンクの長さは、単に任意のまとめを含むように増加されます。そのためRDMA書き込みチャンクが隙間なく連続的に満たされている要件のため、このような状況は、最終的なチャンクの受信データに発生する可能性があります。したがって、ラウンドアップデータはXDRストリームにずれ又は位置にギャップを挿入するための機会は存在しません。
The RDMA transport for RPC provides three methods of moving data between RPC client and server:
RPCのためのRDMAトランスポートは、RPCクライアントとサーバ間でデータを移動する3つの方法が用意されています。
Inline Data is moved between RPC client and server within an RDMA Send.
インラインデータは、RDMA送信中にRPCクライアントとサーバ間で移動されます。
RDMA Read Data is moved between RPC client and server via an RDMA Read operation via steering tag; address and offset obtained from a read chunk list.
RDMA読み取られたデータは、ステアリングタグを介したRDMA読み取り操作を介したRPCクライアントとサーバ間で移動されます。アドレスとリードチャンクのリストから取得したオフセット。
RDMA Write Result data is moved from RPC server to client via an RDMA Write operation via steering tag; address and offset obtained from a write chunk list or reply chunk in the client's RPC call message.
RDMA書き込み結果のデータは、ステアリングタグを介してRDMA書き込み操作を介してクライアントにRPCサーバーから移動されます。クライアントのRPC呼び出しメッセージでの書き込みチャンクリストまたは返信チャンクから取得したアドレスとオフセット。
These methods of data movement may occur in combinations within a single RPC. For instance, an RPC call may contain some inline data along with some large chunks to be transferred via RDMA Read to the server. The reply to that call may have some result chunks that the server RDMA Writes back to the client. The following protocol interactions illustrate RPC calls that use these methods to move RPC message data:
データ移動のこれらの方法は、単一のRPC内の組み合わせで行うことができます。例えば、RPCコールは、いくつかの大きな塊と一緒に、いくつかのインライン・データがサーバにRDMA読み取りを介して転送することが含まれていてもよいです。その呼び出しに対する応答は、サーバRDMAは、クライアントに書き戻すいくつかの結果チャンクを有することができます。以下のプロトコル相互作用は、RPCメッセージデータを移動するために、これらの方法を使用してRPCコールを示します。
An RPC with write chunks in the call message:
コール・メッセージに書き込みチャンクとRPC：
RPC Client RPC Server
| RPC Call + Write Chunk list |
Send | ------------------------------> |
| |
| Chunk 1 |
| <------------------------------ | Write
| : |
| Chunk n |
| <------------------------------ | Write
| |
| RPC Reply |
| <------------------------------ | Send
In the presence of write chunks, RDMA ordering provides the guarantee that all data in the RDMA Write operations has been placed in memory prior to the client's RPC reply processing.
書き込みチャンクの存在下では、RDMAの順序は、RDMA書き込み操作ですべてのデータが前に、クライアントのRPC応答処理にメモリに配置された保証を提供します。
An RPC with read chunks in the call message:
呼び出しメッセージのリードチャンクとRPC：
RPC Client RPC Server
| RPC Call + Read Chunk list |
Send | ------------------------------> |
| |
| Chunk 1 |
| +------------------------------ | Read
| v-----------------------------> |
| : |
| Chunk n |
| +------------------------------ | Read
| v-----------------------------> |
| |
| RPC Reply |
| <------------------------------ | Send
An RPC with read chunks in the reply message:
応答メッセージのリードチャンクとRPC：
RPC Client RPC Server
| RPC Call |
Send | ------------------------------> |
| |
| RPC Reply + Read Chunk list |
| <------------------------------ | Send
| |
| Chunk 1 |
Read | ------------------------------+ |
| <-----------------------------v |
| : |
| Chunk n |
Read | ------------------------------+ |
| <-----------------------------v |
| |
| Done |
Send | ------------------------------> |
The final Done message allows the RPC client to signal the server that it has received the chunks, so the server can de-register and free the memory holding the chunks. A Done completion is not necessary for an RPC call, since the RPC reply Send is itself a receive completion notification. In the event that the client fails to return the Done message within some timeout period, the server MAY conclude that a protocol violation has occurred and close the RPC connection, or it MAY proceed with a de-register and free its chunk buffers. This may result in a fatal RDMA error if the client later attempts to perform an RDMA Read operation, which amounts to the same thing.
サーバは、登録解除とチャンクを保持するメモリを解放できるように最終完了メッセージは、RPCクライアントは、それがチャンクを受信したサーバに信号を送ることを可能にします。 RPC応答送信が受信完了通知そのものであるので、完了完了は、RPC呼び出しのために必要ではありません。クライアントは、いくつかのタイムアウト期間内に完了のメッセージを返すことに失敗した場合には、サーバーは、プロトコル違反が発生したことを結論とRPC接続を閉じる、またはそれは、デ登録し、無料のチャンクバッファを進める場合があります。クライアントが後で同じことになるRDMA読み取り操作を実行しようとする場合、これは致命的なRDMAエラーになることがあります。
The use of read chunks in RPC reply messages is much less efficient than providing write chunks in the originating RPC calls, due to the additional message exchanges, the need for the RPC server to advertise buffers to the peer, the necessity of the server maintaining a timer for the purpose of recovery from misbehaving clients, and the need for additional memory registration. Their use is NOT RECOMMENDED by upper layers where efficiency is a primary concern [RFC5667]. However, they MAY be employed by upper-layer protocol bindings that are primarily concerned with transparency, since they can frequently be implemented completely within the RPC lower layers.
RPC応答メッセージのリードチャンクの使用はあまり効率的により追加のメッセージ交換に、元のRPC呼び出しで書き込みチャンクを提供するよりも、ピアにバッファを宣伝するRPCサーバーの必要性は、サーバーの必要性を維持ふらちなクライアントからの回復を目的とし、追加のメモリ登録の必要性のためのタイマー。それらの使用は効率が主要な関心事[RFC5667]は、上位層によって推奨されません。しかし、それらはしばしばRPC下位層内に完全に実装することができるので、透明性を有する主に懸念している上位層プロトコルバインディングによって使用されてもよいです。
It is important to note that the Done message consumes a credit at the RPC server. The RPC server SHOULD provide sufficient credits to the client to allow the Done message to be sent without deadlock (driving the outstanding credit count to zero). The RPC client MUST account for its required Done messages to the server in its accounting of available credits, and the server SHOULD replenish any credit consumed by its use of such exchanges at its earliest opportunity.
DoneメッセージがRPCサーバーでクレジットを消費することに注意することが重要です。 RPCサーバーは、Doneメッセージがデッドロック（ゼロに優れたクレジット数を駆動）なしで送信できるようにするために、クライアントに十分なクレジットを提供する必要があります。 RPCクライアントは、利用可能なクレジットの会計内のサーバーへの必要な実行されたメッセージを考慮しなければならない、とサーバーは最も早い機会に、このような交流の使用によって消費任意のクレジットを補充すべきです。
Finally, it is possible to conceive of RPC exchanges that involve any or all combinations of write chunks in the RPC call, read chunks in the RPC call, and read chunks in the RPC reply. Support for such exchanges is straightforward from a protocol perspective, but in practice such exchanges would be quite rare, limited to upper-layer protocol exchanges that transferred bulk data in both the call and corresponding reply.
最後に、RPCコールで書き込みチャンクのいずれかまたは全ての組み合わせを伴うRPCの交換を想像RPCコールでチャンクを読み、RPC応答でチャンクを読み取ることが可能です。そのような交換のためのサポートは、プロトコルの観点から簡単であるが、実際にはそのような交換は、呼及び対応する応答の両方バルクデータ転送上位層プロトコル交換に限定され、非常にまれであろう。
Alignment of specific opaque data enables certain scatter/gather optimizations. Padding leverages the useful property that RDMA transfers preserve alignment of data, even when they are placed into pre-posted receive buffers by Sends.
特定の不透明なデータのアライメントは、特定の分散/収集の最適化を可能にします。パディングは、RDMA転送は、それらが送信によって予め投稿受信バッファに配置された場合でも、データの位置合わせを維持する有用な特性を活用します。
Many servers can make good use of such padding. Padding allows the chaining of RDMA receive buffers such that any data transferred by RDMA on behalf of RPC requests will be placed into appropriately aligned buffers on the system that receives the transfer. In this way, the need for servers to perform RDMA Read to satisfy all but the largest client writes is obviated.
多くのサーバは、このようなパディングを十分に活用することができます。パディングは、RDMAの連鎖は、RPCリクエストの代わりにRDMAによって転送される任意のデータ転送を受信するシステムに適切に整列バッファに配置されるように受信バッファを可能にします。このように、サーバはすべてが、最大のクライアントの書き込みを満たすために、RDMA読み取りを実行するために必要性が回避されます。
The effect of padding is demonstrated below showing prior bytes on an XDR stream ("XXX" in the figure below) followed by an opaque field consisting of four length bytes ("LLLL") followed by data bytes ("DDD"). The receiver of the RDMA Send has posted two chained receive buffers. Without padding, the opaque data is split across the two buffers. With the addition of padding bytes ("ppp") prior to the first data byte, the data can be forced to align correctly in the second buffer.
詰め物の効果は、データバイト（「DDD」）に続く4バイト長からなる不透明なフィールド（「LLLL」）、続いて（下図の「XXX」）XDRストリームに先行バイトを示す下に示されています。 RDMAの送信の受信機は、チェーン2の受信バッファを掲載しています。パディングなしで、不透明なデータは、二つのバッファにまたがって分割されます。最初のデータ・バイトの前にパディングバイト（「PPP」）を加えて、データは、第2のバッファに正しく整列するように強制することができます。
Buffer 1 Buffer 2
Unpadded -------------- --------------
XXXXXXXLLLLDDDDDDDDDDDDDD ---> XXXXXXXLLLLDDD DDDDDDDDDDD
Padded
パッド入り
XXXXXXXLLLLpppDDDDDDDDDDDDDD ---> XXXXXXXLLLLppp DDDDDDDDDDDDDD
Padding is implemented completely within the RDMA transport encoding, flagged with a specific message type. Where padding is applied, two values are passed to the peer: an "rdma_align", which is the padding value used, and "rdma_thresh", which is the opaque data size at or above which padding is applied. For instance, if the server is using chained 4 KB receive buffers, then up to (4 KB - 1) padding bytes could be used to achieve alignment of the data. The XDR routine at the peer MUST consult these values when decoding opaque values. Where the decoded length exceeds the rdma_thresh, the XDR decode MUST skip over the appropriate padding as indicated by rdma_align and the current XDR stream position.
パディングは、特定のメッセージタイプでフラグが立てられ、RDMA転送エンコーディング内に完全に実装されています。使用されるパディング値である「rdma_align」、および「rdma_thresh」、パディングが適用されるか、または上記れる不透明なデータサイズである：パディングが適用される場合、2つの値は、ピアに渡されます。例えば、サーバが使用している場合は4キロバイト（4 KB - 1）まで、次いで、受信バッファ連鎖パディングバイトがデータの位置合わせを達成するために使用することができます。不透明な値を復号する際に、ピアでXDRルーチンは、これらの値を参照する必要があります。デコードされた長さがrdma_threshを超える場合rdma_alignと現在XDRストリームの位置によって示されるように、XDRデコードは適切なパディングをスキップしなければなりません。
RPC call and reply messages are conveyed across an RDMA transport with a prepended RPC-over-RDMA header. The RPC-over-RDMA header includes data for RDMA flow control credits, padding parameters, and lists of addresses that provide direct data placement via RDMA Read and Write operations. The layout of the RPC message itself is unchanged from that described in [RFC5531] except for the possible exclusion of large data chunks that will be moved by RDMA Read or Write operations. If the RPC message (along with the RPC-over-RDMA header) is too long for the posted receive buffer (even after any large chunks are removed), then the entire RPC message MAY be moved separately as a chunk, leaving just the RPC-over-RDMA header in the RDMA Send.
RPCコールと返信メッセージがプリペンドRPCオーバーRDMAヘッダとRDMA転送を横切って搬送されます。 RPCオーバーRDMAヘッダは、RDMAフロー制御クレジット、パディングパラメータ、およびRDMA読む経由して直接データ配置を提供し、運用を書くアドレスのリストのデータが含まれています。 RPCメッセージ自体のレイアウトは、RDMA読み取りによって移動または動作を記述する大型データチャンクの可能な排除を除い[RFC5531]に記載されたものと変わりません。 （RPCオーバーRDMAヘッダと共に）RPCメッセージが長すぎる投稿（任意の大きな塊が除去された後でも）、その後、全体のRPCメッセージはRPCだけを残し、チャンクとして別々に移動することができるバッファを受信するためのものである場合RDMAの送信に-over-RDMAヘッダ。
The RPC-over-RDMA header begins with four 32-bit fields that are always present and that control the RDMA interaction including RDMA-specific flow control. These are then followed by a number of items such as chunk lists and padding that MAY or MUST NOT be present depending on the type of transmission. The four fields that are always present are:
RPCオーバーRDMAヘッダが常に存在し、それはRDMA固有のフロー制御を含むRDMA相互作用を制御する4つの32ビット・フィールドで始まります。これらは、その後、または伝送のタイプに応じて存在してはならないもしれチャンクリストおよびパディングなどの項目の数が続きます。常に存在している四つのフィールドは以下のとおりです。
1. Transaction ID (XID). The XID generated for the RPC call and reply. Having the XID at the beginning of the message makes it easy to establish the message context. This XID MUST be the same as the XID in the RPC header. The receiver MAY perform its processing based solely on the XID in the RPC-over-RDMA header, and thereby ignore the XID in the RPC header, if it so chooses.
1.トランザクションID（XID）。 XIDは、RPC呼び出しと応答を生成しました。メッセージの先頭にXIDを持つことは、メッセージコンテキストを確立することが容易になります。このXIDは、RPCヘッダーのXIDと同じでなければなりません。受信機は、RPCオーバーRDMAヘッダにXIDのみに基づいてその処理を実行し、それによってそれがそう選択した場合、RPCヘッダにXIDを無視してもよいです。
2. Version number. This version of the RPC RDMA message protocol is 1. The version number MUST be increased by 1 whenever the format of the RPC RDMA messages is changed.
2.バージョン番号。 RPC RDMAメッセージプロトコルのこのバージョンでは、RPCのRDMAメッセージのフォーマットが変更されるたびに、バージョン番号が1だけ増加させなければならない1です。
3. Flow control credit value. When sent in an RPC call message, the requested value is provided. When sent in an RPC reply message, the granted value is returned. RPC calls SHOULD NOT be sent in excess of the currently granted limit.
3.フロー制御クレジット値。 RPC呼び出しメッセージで送信された場合は、要求された値が提供されています。 RPC応答メッセージで送信された場合には、付与された値が返されます。 RPCコールは、現在許可された限度を超えて送るべきではありません。
o RDMA_MSG = 0 indicates that chunk lists and RPC message follow.
O RDMA_MSG = 0は、そのチャンクのリストとRPCメッセージのフォローを示します。
o RDMA_NOMSG = 1 indicates that after the chunk lists there is no RPC message. In this case, the chunk lists provide information to allow the message proper to be transferred using RDMA Read or Write and thus is not appended to the RPC-over-RDMA header.
O RDMA_NOMSG = 1は、チャンクが一覧表示されます後に何のRPCメッセージがないことを示しています。この場合、チャンクリストは、適切なメッセージがRDMA読み取りを使用して転送または書き込みしたがってRPCオーバーRDMAヘッダに付加されていないことを可能にする情報を提供します。
o RDMA_MSGP = 2 indicates that a chunk list and RPC message with some padding follow.
O RDMA_MSGP = 2は、いくつかのパディングを持つチャンクのリストとRPCメッセージが続くことを示しています。
o RDMA_DONE = 3 indicates that the message signals the completion of a chunk transfer via RDMA Read.
O RDMA_DONE = 3メッセージがRDMA読み取り介しチャンク転送の完了を知らせることを示しています。
o RDMA_ERROR = 4 is used to signal any detected error(s) in the RPC RDMA chunk encoding.
O RDMA_ERROR = 4は、RPC RDMAチャンクエンコーディングの任意の検出されたエラー（複数可）を通知するために使用されます。
Because the version number is encoded as part of this header, and the RDMA_ERROR message type is used to indicate errors, these first four fields and the start of the following message body MUST always remain aligned at these fixed offsets for all versions of the RPC-over-RDMA header.
バージョン番号がこのヘッダの一部として符号化され、RDMA_ERRORメッセージタイプは、エラーを示すために使用されているので、これらの最初の4つのフィールドと、次のメッセージボディの開始は常にRPC-のすべてのバージョンのためにこれらの固定オフセットで整列したままでなければなりません過RDMAヘッダ。
For a message of type RDMA_MSG or RDMA_NOMSG, the Read and Write chunk lists follow. If the Read chunk list is null (a 32-bit word of zeros), then there are no chunks to be transferred separately and the RPC message follows in its entirety. If non-null, then it's the beginning of an XDR encoded sequence of Read chunk list entries. If the Write chunk list is non-null, then an XDR encoded sequence of Write chunk entries follows.
型RDMA_MSGまたはRDMA_NOMSGのメッセージについては、読み取りおよび書き込みチャンクリストが続きます。読み取りチャンクリスト（ゼロの32ビットワード）がnullである場合には、別途転送すべきチャンクがないとRPCメッセージは、その全体が続きます。 null以外の場合、それは読むチャンクリストエントリのXDRエンコードされたシーケンスの始まりです。書き込みチャンクリストが非nullの場合、書き込みチャンクエントリのXDRコードされる配列は以下のとおりです。
If the message type is RDMA_MSGP, then two additional fields that specify the padding alignment and threshold are inserted prior to the Read and Write chunk lists.
メッセージタイプがRDMA_MSGPであれば、パディングアライメントやしきい値を指定する2つの追加フィールドを読む前に挿入され、チャンクのリストを作成しています。
A header of message type RDMA_MSG or RDMA_MSGP MUST be followed by the RPC call or RPC reply message body, beginning with the XID. The XID in the RDMA_MSG or RDMA_MSGP header MUST match this.
メッセージタイプRDMA_MSG又はRDMA_MSGPのヘッダは、XID始まる、RPCコールまたはRPC応答メッセージのボディが続かなければなりません。 RDMA_MSG又はRDMA_MSGPヘッダ内のXIDは、これを一致しなければなりません。
+--------+---------+---------+-----------+-------------+----------
| | | | Message | NULLs | RPC Call
| XID | Version | Credits | Type | or | or
| | | | | Chunk Lists | Reply Msg
+--------+---------+---------+-----------+-------------+----------
Note that in the case of RDMA_DONE and RDMA_ERROR, no chunk list or RPC message follows. As an implementation hint: a gather operation on the Send of the RDMA RPC message can be used to marshal the initial header, the chunk list, and the RPC message itself.
RDMA_DONEとRDMA_ERRORの場合には、何のチャンクリストまたはRPCメッセージは以下のないことに注意してください。実装のヒントとして：RDMAのRPCメッセージの送信の操作を収集初期ヘッダ、チャンクのリスト、およびRPCメッセージ自体をマーシャリングするために使用することができます。
When a peer receives an RPC RDMA message, it MUST perform the following basic validity checks on the header and chunk contents. If such errors are detected in the request, an RDMA_ERROR reply MUST be generated.
ピアがRPC RDMAメッセージを受信すると、ヘッダ及びチャンクの内容に以下の基本的な妥当性チェックを実行しなければなりません。そのようなエラーが要求に検出された場合、RDMA_ERROR応答が生成されなければなりません。
Two types of errors are defined, version mismatch and invalid chunk format. When the peer detects an RPC-over-RDMA header version that it does not support (currently this document defines only version 1), it replies with an error code of ERR_VERS, and provides the low and high inclusive version numbers it does, in fact, support. The version number in this reply MUST be any value otherwise valid at the receiver. When other decoding errors are detected in the header or chunks, either an RPC decode error MAY be returned or the RPC/RDMA error code ERR_CHUNK MUST be returned.
エラーの二つのタイプは、バージョンの不一致や無効なチャンク形式を定義しています。ピアが（現在、このドキュメントは、唯一のバージョン1を定義）がサポートされていないRPCオーバーRDMAヘッダのバージョンを検出すると、ERR_VERSのエラーコードで応答し、そして実際にはそれがない低および高包括バージョン番号を、提供します、 サポート。この回答にバージョン番号は、受信機でそれ以外の場合は、有効な任意の値でなければなりません。他の復号誤りは、ヘッダまたはチャンクに検出されたときのいずれかRPCデコードエラーが返されることがあり、またはRPC / RDMAエラーコードERR_CHUNKが返さなければなりません。
Here is the message layout in XDR language.
ここではXDR言語でメッセージのレイアウトがあります。
struct xdr_rdma_segment {
uint32 handle; /* Registered memory handle */
uint32 length; /* Length of the chunk in bytes */
uint64 offset; /* Chunk virtual address or offset */
};
struct xdr_read_chunk {
uint32 position; /* Position in XDR stream */
struct xdr_rdma_segment target;
};
struct xdr_read_list {
struct xdr_read_chunk entry;
struct xdr_read_list *next;
};
struct xdr_write_chunk {
struct xdr_rdma_segment target<>;
};
struct xdr_write_list {
struct xdr_write_chunk entry;
struct xdr_write_list *next;
};
struct rdma_msg {
uint32 rdma_xid; /* Mirrors the RPC header xid */
uint32 rdma_vers; /* Version of this protocol */
uint32 rdma_credit; /* Buffers requested/granted */
rdma_body rdma_body;
};
enum rdma_proc {
RDMA_MSG=0, /* An RPC call or reply msg */
RDMA_NOMSG=1, /* An RPC call or reply msg - separate body */
RDMA_MSGP=2, /* An RPC call or reply msg with padding */
RDMA_DONE=3, /* Client signals reply completion */
RDMA_ERROR=4 /* An RPC RDMA encoding error */
};
union rdma_body switch (rdma_proc proc) {
case RDMA_MSG:
rpc_rdma_header rdma_msg;
case RDMA_NOMSG:
rpc_rdma_header_nomsg rdma_nomsg;
case RDMA_MSGP:
rpc_rdma_header_padded rdma_msgp;
case RDMA_DONE:
void;
case RDMA_ERROR:
rpc_rdma_error rdma_error;
};
struct rpc_rdma_header {
struct xdr_read_list *rdma_reads;
struct xdr_write_list *rdma_writes;
struct xdr_write_chunk *rdma_reply;
/* rpc body follows */
};
struct rpc_rdma_header_nomsg {
struct xdr_read_list *rdma_reads;
struct xdr_write_list *rdma_writes;
struct xdr_write_chunk *rdma_reply;
};
｝；
struct rpc_rdma_header_padded {
uint32 rdma_align; /* Padding alignment */
uint32 rdma_thresh; /* Padding threshold */
struct xdr_read_list *rdma_reads;
struct xdr_write_list *rdma_writes;
struct xdr_write_chunk *rdma_reply;
/* rpc body follows */
};
enum rpc_rdma_errcode { ERR_VERS = 1, ERR_CHUNK = 2 };
列挙rpc_rdma_errcode {ERR_VERS = 1、ERR_CHUNK = 2}。
union rpc_rdma_error switch (rpc_rdma_errcode err) {
case ERR_VERS:
uint32 rdma_vers_low;
uint32 rdma_vers_high;
case ERR_CHUNK:
void;
default:
uint32 rdma_extra[8];
};
The receiver of RDMA Send messages is required by RDMA to have previously posted one or more adequately sized buffers. The RPC client can inform the server of the maximum size of its RDMA Send messages via the Connection Configuration Protocol described later in this document.
RDMAの受信メッセージを送信しますが、以前に掲載さ一つ以上の適切なサイズのバッファを持つことがRDMAによって必要とされます。 RPCクライアントは、そのRDMAの最大サイズのサーバが構成プロトコルは、このドキュメントで後述する接続を経由してメッセージを送信し通知することができます。
Since RPC messages are frequently small, memory savings can be achieved by posting small buffers. Even large messages like NFS READ or WRITE will be quite small once the chunks are removed from the message. However, there may be large messages that would demand a very large buffer be posted, where the contents of the buffer may not be a chunkable XDR element. A good example is an NFS READDIR reply, which may contain a large number of small filename strings. Also, the NFS version 4 protocol [RFC3530] features COMPOUND request and reply messages of unbounded length.
RPCメッセージが頻繁に小さいので、メモリの節約は小さなバッファを掲載することにより達成することができます。チャンクがメッセージから削除されるとNFS READまたはWRITEのようにも大きなメッセージは非常に小さくなります。しかし、バッファの内容はchunkable XDR要素ではないかもしれない非常に大きなバッファを要求するだろう大きなメッセージ投稿することがあってもよいです。良い例は、小さいファイル名の文字列の多数を含んでいてもよいNFS READDIR応答です。また、NFSバージョン4プロトコル[RFC3530]は無限の長さの複合要求および応答メッセージがあります。
Ideally, each upper layer will negotiate these limits. However, it is frequently necessary to provide a transparent solution.
理想的には、各上位層には、これらの制限をネゴシエートします。しかし、透明な溶液を提供するために、しばしば必要です。
One relatively simple method is to have the client identify any RPC message that exceeds the RPC server's posted buffer size and move it separately as a chunk, i.e., reference it as the first entry in the read chunk list with an XDR position of zero.
一方、比較的簡単な方法は、クライアントがRPCサーバーの通知バッファサイズを超えると、すなわち、ゼロのXDR位置にリードチャンクのリストの最初のエントリとしてそれを参照、チャンクとして別々に移動任意のRPCメッセージを識別することです。
Normal Message
通常のメッセージ
+--------+---------+---------+------------+-------------+----------
| | | | | | RPC Call
| XID | Version | Credits | RDMA_MSG | Chunk Lists | or
| | | | | | Reply Msg
+--------+---------+---------+------------+-------------+----------
Long Message
長いメッセージ
+--------+---------+---------+------------+-------------+
| | | | | |
| XID | Version | Credits | RDMA_NOMSG | Chunk Lists |
| | | | | |
+--------+---------+---------+------------+-------------+
|
| +----------
| | Long RPC Call
+->| or
| Reply Message
+----------
If the receiver gets an RPC-over-RDMA header with a message type of RDMA_NOMSG and finds an initial read chunk list entry with a zero XDR position, it allocates a registered buffer and issues an RDMA Read of the long RPC message into it. The receiver then proceeds to XDR decode the RPC message as if it had received it inline with the Send data. Further decoding may issue additional RDMA Reads to bring over additional chunks.
受信機はRDMA_NOMSGのメッセージタイプでRPCオーバーRDMAのヘッダを取得し、ゼロXDR位置に初期読み出しチャンクリストエントリが見つかった場合、それは、登録バッファを割り当て、そこに長いRPCメッセージのRDMA読み取りを発行します。受信機は、それが送信データとインラインでそれを受け取ったかのようにRPCメッセージをデコードXDRへ進みます。追加のRDMAを発行することができるさらなるデコードは、追加のチャンクを超える持って読み込みます。
Although the handling of long messages requires one extra network turnaround, in practice these messages will be rare if the posted receive buffers are correctly sized, and of course they will be non-existent for RDMA-aware upper layers.
長いメッセージの取り扱いは、1つの余分のネットワーク・ターンアラウンドを必要としますが、受信掲示バッファが適切なサイズであれば、実際にこれらのメッセージはまれになり、そしてもちろん、彼らはRDMA対応の上位層のために存在しないだろう。
A long call RPC with request supplied via RDMA Read
RDMA読む介して供給される要求に長いコールRPC
RPC Client RPC Server
| RDMA-over-RPC Header |
Send | ------------------------------> |
| |
| Long RPC Call Msg |
| +------------------------------ | Read
| v-----------------------------> |
| |
| RDMA-over-RPC Reply |
| <------------------------------ | Send
An RPC with long reply returned via RDMA Read
長い応答でRPCは、RDMAリードを介して返さ
RPC Client RPC Server
| RPC Call |
Send | ------------------------------> |
| |
| RDMA-over-RPC Header |
| <------------------------------ | Send
| |
| Long RPC Reply Msg |
Read | ------------------------------+ |
| <-----------------------------v |
| |
| Done |
Send | ------------------------------> |
It is possible for a single RPC procedure to employ both a long call for its arguments and a long reply for its results. However, such an operation is atypical, as few upper layers define such exchanges.
単一のRPCプロシージャは、その引数のための長い呼び出し、その結果を得るために長い応答の両方を採用することが可能です。いくつかの上位層は、そのような交換を定義しかし、このような動作は、非定型です。
A superior method of handling long RPC replies is to have the RPC client post a large buffer into which the server can write a large RPC reply. This has the advantage that an RDMA Write may be slightly faster in network latency than an RDMA Read, and does not require the server to wait for the completion as it must for RDMA Read. Additionally, for a reply it removes the need for an RDMA_DONE message if the large reply is returned as a Read chunk.
長いRPCの応答を処理する優れた方法は、RPCクライアントは、サーバが大規模なRPC応答を書き込むことができるに大きなバッファを投稿することです。これは、RDMA書き込みがRDMA読むよりも、ネットワークの待ち時間にわずかに速くすることができ、そしてそれはRDMA読むための絶対必要として完了を待つサーバーを必要としないという利点を有します。また、回答のためには、大規模な回答が読むチャンクとして返された場合RDMA_DONEメッセージの必要性を取り除きます。
This protocol supports direct return of a large reply via the inclusion of an OPTIONAL rdma_reply write chunk after the read chunk list and the write chunk list. The client allocates a buffer sized to receive a large reply and enters its steering tag, address and length in the rdma_reply write chunk. If the reply message is too long to return inline with an RDMA Send (exceeds the size of the client's posted receive buffer), even with read chunks removed, then the RPC server performs an RDMA Write of the RPC reply message into the buffer indicated by the rdma_reply chunk. If the client doesn't provide an rdma_reply chunk, or if it's too small, then if the upper-layer specification permits, the message MAY be returned as a Read chunk.
このプロトコルは、読み取りチャンクリストの後にオプションrdma_reply書き込みチャンクを含めると書き込みチャンクリストを経由して大規模な回答の直接のリターンをサポートしています。クライアントは、大規模な応答を受信するような大きさのバッファを割り当て、rdma_reply書き込みチャンクにおけるそのステアリングタグ、アドレスと長さを入力します。応答メッセージは、RDMAの送信をインラインで返すように長すぎる場合は、読み取りのチャンクを削除してもして、（クライアントのサイズは、受信バッファを掲載超えた）、その後、RPCサーバーは、で示されるバッファにRPC応答メッセージのRDMA書き込みを行い、 rdma_replyチャンク。クライアントはrdma_replyチャンクを提供していない、またはそれは小さすぎる場合は、上位層の仕様が許すならば、メッセージは読むのチャンクとして返されることがあります。
An RPC with long reply returned via RDMA Write
長い応答でRPCは、RDMA書き込みを介して返さ
RPC Client RPC Server
| RPC Call with rdma_reply |
Send | ------------------------------> |
| |
| Long RPC Reply Msg |
| <------------------------------ | Write
| |
| RDMA-over-RPC Header |
| <------------------------------ | Send
The use of RDMA Write to return long replies requires that the client applications anticipate a long reply and have some knowledge of its size so that an adequately sized buffer can be allocated. This is certainly true of NFS READDIR replies; where the client already provides an upper bound on the size of the encoded directory fragment to be returned by the server.
長い応答を返すためにRDMAライトの使用は、クライアント・アプリケーションは、長い応答を予測し、適切なサイズのバッファを割り当てることができるように、そのサイズのある程度の知識を持っていることが必要です。これは確かに返信NFS READDIRの事実です。クライアントがすでにサーバによって返されるエンコードされたディレクトリフラグメントのサイズに上限を提供しています。
The use of these "reply chunks" is highly efficient and convenient for both RPC client and server. Their use is encouraged for eligible RPC operations such as NFS READDIR, which would otherwise require extensive chunk management within the results or use of RDMA Read and a Done message [RFC5667].
これらの「返信チャンク」の使用は、RPCクライアントとサーバーの両方のための非常に効率的で便利です。それらの使用は、そうでなければ結果またはRDMA読み取りを使用すると完了メッセージ[RFC5667]内の広範囲のチャンク管理を必要とするであろうNFS READDIR、として適格RPC操作のために奨励されています。
RDMA Send operations require the receiver to post one or more buffers at the RDMA connection endpoint, each large enough to receive the largest Send message. Buffers are consumed as Send messages are received. If a buffer is too small, or if there are no buffers posted, the RDMA transport MAY return an error and break the RDMA connection. The receiver MUST post sufficient, adequately buffers to avoid buffer overrun or capacity errors.
RDMA操作は、最大送信メッセージを受信するのに十分な、各大RDMA接続エンドポイントで、1つ以上のバッファを投稿する受信機が必要に送ります。送信メッセージが受信されるとバッファが消費されています。バッファが小さすぎる、または掲載全くバッファが存在しない場合は、RDMAトランスポートはエラーを返すと、RDMA接続を破損する可能性があります。場合受信機は、バッファオーバーランや容量エラーを回避するのに十分な、十分なバッファを投稿しなければなりません。
The protocol described above includes only a mechanism for managing the number of such receive buffers and no explicit features to allow the RPC client and server to provision or control buffer sizing, nor any other session parameters.
上述のプロトコルは、規定又は制御バッファサイズにRPCクライアントとサーバーを可能にするために、このような受信バッファと明示的な機能の数を管理するためのメカニズム、また、他のセッションパラメータを含みます。
In the past, this type of connection management has not been necessary for RPC. RPC over UDP or TCP does not have a protocol to negotiate the link. The server can get a rough idea of the maximum size of messages from the server protocol code. However, a protocol to negotiate transport features on a more dynamic basis is desirable.
過去には、接続管理のこのタイプは、RPCのために必要とされていません。 UDPまたはTCP上のRPCは、リンクを交渉するためのプロトコルを持っていません。サーバは、サーバプロトコルコードからのメッセージの最大サイズの大まかなアイデアを得ることができます。しかし、よりダイナミックに基づいてトランスポート機能を交渉するためのプロトコルであることが望ましいです。
The Connection Configuration Protocol allows the client to pass its connection requirements to the server, and allows the server to inform the client of its connection limits.
接続構成プロトコルは、クライアントがサーバーへの接続要件を渡すことができます、そして、サーバはその接続制限をクライアントに通知することができます。
Use of the Connection Configuration Protocol by an upper layer is OPTIONAL.
上位層による接続構成プロトコルの使用は任意です。
This protocol MAY be used for connection setup prior to the use of another RPC protocol that uses the RDMA transport. It operates in-band, i.e., it uses the connection itself to negotiate the connection parameters. To provide a basis for connection negotiation, the connection is assumed to provide a basic level of interoperability: the ability to exchange at least one RPC message at a time that is at least 1 KB in size. The server MAY exceed this basic level of configuration, but the client MUST NOT assume more than one, and MUST receive a valid reply from the server carrying the actual number of available receive messages, prior to sending its next request.
このプロトコルは、RDMAトランスポートを使用する別のRPCプロトコルを使用する前に接続セットアップのために使用されるかもしれません。これはすなわち、それが接続パラメータをネゴシエートする接続自体を使用して、帯域内で動作します。サイズが少なくとも1キロバイトである時に少なくとも一つのRPCメッセージを交換する能力：接続ネゴシエーションのための基礎を提供するために、接続は、相互運用性の基本的なレベルを提供するものとします。サーバーは、この構成の基本的なレベルを超えることがありますが、クライアントは、複数のを仮定してはいけません、と前にその次の要求を送信するメッセージを、受信可能なの実際の数を運んで、サーバから有効な応答を受信しなければなりません。
Version 1 of the Connection Configuration Protocol consists of a single procedure that allows the client to inform the server of its connection requirements and the server to return connection information to the client.
接続構成プロトコルのバージョン1は、クライアントが接続要件のサーバーおよびクライアントへの接続情報を返すようにサーバに通知することを可能にする単一の手順で構成されています。
The maxcall_sendsize argument is the maximum size of an RPC call message that the client MAY send inline in an RDMA Send message to the server. The server MAY return a maxcall_sendsize value that is smaller or larger than the client's request. The client MUST NOT send an inline call message larger than what the server will accept. The maxcall_sendsize limits only the size of inline RPC calls. It does not limit the size of long RPC messages transferred as an initial chunk in the Read chunk list.
maxcall_sendsize引数には、クライアントがサーバーにメッセージを送るRDMAにインラインを送るかもしれRPC呼び出しメッセージの最大サイズです。サーバはクライアントの要求よりも小さいか大きいmaxcall_sendsize値を返すことがあります。クライアントは、サーバが受け入れる何よりも大きなインライン呼び出しメッセージを送ってはいけません。 maxcall_sendsize制限インラインRPCコールのサイズのみ。それは読むのチャンク・リストの最初のチャンクとして転送長いRPCメッセージのサイズを制限しません。
The maxreply_sendsize is the maximum size of an inline RPC message that the client will accept from the server.
maxreply_sendsizeは、クライアントがサーバから受け入れるインラインRPCメッセージの最大サイズです。
The maxrdmaread is the maximum number of RDMA Reads that may be active at the peer. This number correlates to the RDMA incoming RDMA Read count ("IRD") configured into each originating endpoint by the client or server. If more than this number of RDMA Read operations by the connected peer are issued simultaneously, connection loss or suboptimal flow control may result; therefore, the value SHOULD be observed at all times. The peers' values need not be equal. If zero, the peer MUST NOT issue requests that require RDMA Read to satisfy, as no transfer will be possible.
maxrdmareadは、RDMAの最大数は、そのピアでアクティブであってもよい読み取ります。この数は、クライアントまたはサーバによって各発信エンドポイントに構成されたRDMAの着信RDMA読み取り回数（「IRD」）と相関します。接続されたピアがRDMA読み取り操作のこの数以上が同時に発行された場合、接続損失又は次善フロー制御が生じ得ます。そのため、値は常に観察されなければなりません。ピアの値が等しい必要はありません。ゼロの場合は何の転送が可能になりませんよう、ピアは、満たすためにRDMA読み取りを必要とする要求を発行してはいけません。
The align value is the value recommended by the server for opaque data values such as strings and counted byte arrays. The client MAY use this value to compute the number of prepended pad bytes when XDR encoding opaque values in the RPC call message.
ALIGN値は、文字列、カウントバイト配列などの不透明なデータ値のサーバによって推奨される値です。クライアントは、XDRがRPCコールメッセージに不透明な値を符号化する際に付加パッドバイトの数を計算するためにこの値を使用することができます。
typedef unsigned int uint32;
unsigned int型のtypedef UINT32。
struct config_rdma_req {
uint32 maxcall_sendsize;
/* max size of inline RPC call */
uint32 maxreply_sendsize;
/* max size of inline RPC reply */
uint32 maxrdmaread;
/* max active RDMA Reads at client */
};
struct config_rdma_reply {
uint32 maxcall_sendsize;
/* max call size accepted by server */
uint32 align;
/* server's receive buffer alignment */
uint32 maxrdmaread;
/* max active RDMA Reads at server */
};
program CONFIG_RDMA_PROG {
version VERS1 {
/*
* Config call/reply
*/
config_rdma_reply CONF_RDMA(config_rdma_req) = 1;
} = 1;
} = 100417;
RDMA requires that all data be transferred between registered memory regions at the source and destination. All protocol headers as well as separately transferred data chunks use registered memory. Since the cost of registering and de-registering memory can be a large proportion of the RDMA transaction cost, it is important to minimize registration activity. This is easily achieved within RPC controlled memory by allocating chunk list data and RPC headers in a reusable way from pre-registered pools.
RDMAは、すべてのデータは、ソースおよび宛先に登録されたメモリ領域との間で転送されることを必要とします。すべてのプロトコルヘッダならびに別々転送されたデータチャンクは、登録されたメモリを使用します。メモリを登録し、登録解除のコストがRDMAトランザクションコストの大部分することができますので、登録の活動を最小限に抑えることが重要です。これは簡単に予め登録プールから再利用可能なようにチャンクリストデータとRPCヘッダを割り当てることによってRPC制御メモリ内に達成されます。
The data chunks transferred via RDMA MAY occupy memory that persists outside the bounds of the RPC transaction. Hence, the default behavior of an RPC-over-RDMA transport is to register and de-register these chunks on every transaction. However, this is not a limitation of the protocol -- only of the existing local RPC API. The API is easily extended through such functions as rpc_control(3) to change the default behavior so that the application can assume responsibility for controlling memory registration through an RPC-provided registered memory allocator.
RDMAを介して転送されたデータチャンクは、RPCトランザクションの境界の外側存続するメモリを占有することができます。したがって、RPCオーバーRDMA輸送のデフォルトの動作では、すべてのトランザクションにこれらのチャンクを登録し、登録解除することです。唯一の既存のローカルのRPC APIの - しかし、これは、プロトコルの制限ではありません。アプリケーションは、RPCが提供する登録メモリアロケータを介してメモリ登録を制御するための責任を負うことができるように、APIを容易に既定の動作を変更するたrpc_control（3）のような機能を介して拡張されます。
RPC RDMA protocol errors are described in Section 4. RPC errors and RPC error recovery are not affected by the protocol, and proceed as for any RPC error condition. RDMA transport error reporting and recovery are outside the scope of this protocol.
RPC RDMAプロトコルエラーは4 RPCエラーとRPCのエラー回復はプロトコルによって影響されないセクションで説明され、任意のRPCエラー条件のためのように進行しています。 RDMAトランスポートエラー報告と回復は、このプロトコルの範囲外です。
It is assumed that the link itself will provide some degree of error detection and retransmission. iWARP's Marker PDU Aligned (MPA) layer (when used over TCP), Stream Control Transmission Protocol (SCTP), as well as the InfiniBand link layer all provide Cyclic Redundancy Check (CRC) protection of the RDMA payload, and CRC-class protection is a general attribute of such transports. Additionally, the RPC layer itself can accept errors from the link level and recover via retransmission. RPC recovery can handle complete loss and re-establishment of the link.
リンク自体が誤り検出と再送信のいくつかの学位を提供することが想定されます。 iWARPののマーカーPDU同盟（MPA）層（TCP上で使用）、ストリーム制御伝送プロトコル（SCTP）のほか、インフィニバンド・リンク層の全てが、RDMAペイロードの巡回冗長検査（CRC）保護、およびCRC-クラスの保護を提供していますそのようなトランスポートの一般的な属性。さらに、RPC層自体は、リンクレベルからエラーを受け入れて再送を介して回復することができます。 RPCの回復は完全に消失し、リンクの再確立を処理することができます。
See Section 11 for further discussion of the use of RPC-level integrity schemes to detect errors and related efficiency issues.
エラーと関連する効率の問題を検出するためのRPCレベルの整合性スキームの使用のさらなる議論については、セクション11を参照してください。
In setting up a new RDMA connection, the first action by an RPC client will be to obtain a transport address for the server. The mechanism used to obtain this address, and to open an RDMA connection is dependent on the type of RDMA transport, and is the responsibility of each RPC protocol binding and its local implementation.
新しいRDMA接続をセットアップするには、RPCクライアントによる最初のアクションは、サーバーのトランスポートアドレスを取得することになります。このアドレスを取得するために、及びRDMA接続を開くために使用されるメカニズムは、RDMA転送のタイプに依存し、各RPCプロトコルバインディングとそのローカル実装の責任です。
RPC services normally register with a portmap or rpcbind [RFC1833] service, which associates an RPC program number with a service address. (In the case of UDP or TCP, the service address for NFS is normally port 2049.) This policy is no different with RDMA interconnects, although it may require the allocation of port numbers appropriate to each upper-layer binding that uses the RPC framing defined here.
RPCサービスは、通常はサービスアドレスでRPCプログラム番号を関連付けるのportmapまたはrpcbindの[RFC1833]サービス、に登録します。それはRPCフレーミングを使用して結合、各上位層に適切なポート番号の割り当てを必要とするかもしれないが、このポリシーは、RDMA配線と異なっていない（UDPまたはTCPの場合には、NFSのサービスアドレスは、2049通常のポートです）ここで定義されました。
When mapped atop the iWARP [RFC5040, RFC5041] transport, which uses IP port addressing due to its layering on TCP and/or SCTP, port mapping is trivial and consists merely of issuing the port in the connection process. The NFS/RDMA protocol service address has been assigned port 20049 by IANA, for both iWARP/TCP and iWARP/SCTP.
TCP及び/又はSCTP上の積層によるアドレッシングのIPポートを使用するiWARPの[RFC5040、RFC5041]輸送、の上にマッピングされた場合、ポートマッピングは自明であり、接続プロセスのポート発行の単なる構成されています。 NFS / RDMAプロトコルサービスのアドレスは、iWARPの/ TCPおよびiWARPの/ SCTPの両方のために、IANAによってポート20049が割り当てられています。
When mapped atop InfiniBand [IB], which uses a Group Identifier (GID)-based service endpoint naming scheme, a translation MUST be employed. One such translation is defined in the InfiniBand Port Addressing Annex [IBPORT], which is appropriate for translating IP port addressing to the InfiniBand network. Therefore, in this case, IP port addressing may be readily employed by the upper layer.
グループID（GID）ベースのサービス・エンドポイントの名前付けスキームを使用したInfiniBand [IB]、の上にマッピングされた場合に、翻訳が使用されなければなりません。そのような翻訳は、InfiniBandネットワークにIPアドレス指定ポートを翻訳するための適切な附属書[IBPORT]を、アドレス指定のInfiniBandポートに定義されています。したがって、この場合には、IPアドレス指定ポートが容易に上位層によって使用されてもよいです。
When a mapping standard or convention exists for IP ports on an RDMA interconnect, there are several possibilities for each upper layer to consider:
マッピング規格または規約がRDMA相互接続上のIPポートに存在する場合、考慮すべき各上位層にはいくつかの可能性があります。
One possibility is to have an upper-layer server register its mapped IP port with the rpcbind service, under the netid (or netid's) defined here. An RPC/RDMA-aware client can then resolve its desired service to a mappable port, and proceed to connect. This is the most flexible and compatible approach, for those upper layers that are defined to use the rpcbind service.
一つの可能性は、上位層のサーバは、ここで定義されたNETID（またはNETIDの）の下で、rpcbindサービスとのマッピングされたIPポートを登録することです。 RPC / RDMA対応のクライアントは、マッピング可能なポートにその所望のサービスを解決し、接続するために進むことができます。これは、rpcbindサービスを使用するように定義されるそれらの上位層に対して、最も柔軟で適合性のアプローチです。
A second possibility is to have the server's portmapper register itself on the RDMA interconnect at a "well known" service address. (On UDP or TCP, this corresponds to port 111.) A client could connect to this service address and use the portmap protocol to obtain a service address in response to a program number, e.g., an iWARP port number, or an InfiniBand GID.
第2の可能性は、サーバーのポートマッパーは、「周知の」サービスアドレスでRDMAの相互接続に自身を登録することです。クライアントは、このサービスのアドレスに接続し、プログラム番号、例えば、iWARPのポート番号、またはインフィニバンドGIDに応答してサービスアドレスを取得するためにポートマッププロトコルを使用することができ（UDPまたはTCPでは、これはポート111に相当します）。
Alternatively, the client could simply connect to the mapped well-known port for the service itself, if it is appropriately defined. By convention, the NFS/RDMA service, when operating atop such an InfiniBand fabric, will use the same 20049 assignment as for iWARP.
それが適切に定義されている場合は別の方法として、クライアントは単に、サービス自体のマッピングされた既知のポートに接続することができます。慣例により、NFS / RDMAサービスは、InfiniBandファブリックの上に動作しているときに、iWARPのと同じ20049割り当てを使用します。
Historically, different RPC protocols have taken different approaches to their port assignment; therefore, the specific method is left to each RPC/RDMA-enabled upper-layer binding, and not addressed here.
歴史的に、異なるRPCプロトコルは、そのポートの割り当てに異なるアプローチをとっています。従って、具体的な方法は、結合、各RPC / RDMA対応の上層に残され、そしてここで取り上げられていません。
In Section 12, "IANA Considerations", this specification defines two new "netid" values, to be used for registration of upper layers atop iWARP [RFC5040, RFC5041] and (when a suitable port translation service is available) InfiniBand [IB]. Additional RDMA-capable networks MAY define their own netids, or if they provide a port translation, MAY share the one defined here.
iWARPの頂上上層の登録に使用される第12において、「IANAの考慮事項」は、本明細書は、2つの新しい「NETID」値を定義し、[RFC5040、RFC5041]及び（適切なポート翻訳サービスが利用可能である）のInfiniBand [IB]。追加のRDMA対応ネットワークは独自のnetidsを定義したり、彼らはポート変換を提供する場合、ここで定義されたものを共有することがあります。
RPC provides its own security via the RPCSEC_GSS framework [RFC2203]. RPCSEC_GSS can provide message authentication, integrity checking, and privacy. This security mechanism will be unaffected by the RDMA transport. The data integrity and privacy features alter the body of the message, presenting it as a single chunk. For large messages the chunk may be large enough to qualify for RDMA Read transfer. However, there is much data movement associated with computation and verification of integrity, or encryption/decryption, so certain performance advantages may be lost.
RPCは、RPCSEC_GSSフレームワーク[RFC2203]を経由して、独自のセキュリティを提供します。 RPCSEC_GSSは、メッセージ認証、整合性チェック、およびプライバシーを提供することができます。このセキュリティメカニズムは、RDMA輸送の影響を受けないだろう。データの整合性とプライバシーを単一のチャンクとして、それを提示し、メッセージの本文を変更します。大きなメッセージのためにチャンクはRDMAリード転送のために修飾するのに十分な大きさがあります。しかし、計算との整合性の検証、または暗号化/復号化に関連した多くのデータ移動があるので、特定のパフォーマンス上の利点が失われることがあります。
For efficiency, a more appropriate security mechanism for RDMA links may be link-level protection, such as certain configurations of IPsec, which may be co-located in the RDMA hardware. The use of link-level protection MAY be negotiated through the use of the new RPCSEC_GSS mechanism defined in [RFC5403] in conjunction with the Channel Binding mechanism [RFC5056] and IPsec Channel Connection Latching [RFC5660]. Use of such mechanisms is REQUIRED where integrity and/or privacy is desired, and where efficiency is required.
効率のために、RDMAリンクのためのより適切なセキュリティメカニズムは、RDMAハードウェアに位置していてもよいのIPsecの特定の構成、等のリンクレベル保護であってもよいです。リンクレベルの保護を使用することは、チャネルバインディング機構[RFC5056]及び[RFC5660]をラッチのIPsecチャネル接続に関連して、[RFC5403]で定義された新たなRPCSEC_GSSメカニズムの使用を介して交渉されるかもしれません。完全性及び/又はプライバシーが所望される場合、効率が要求されるような機構の使用が必要です。
An additional consideration is the protection of the integrity and privacy of local memory by the RDMA transport itself. The use of RDMA by RPC MUST NOT introduce any vulnerabilities to system memory contents, or to memory owned by user processes. These protections are provided by the RDMA layer specifications, and specifically their security models. It is REQUIRED that any RDMA provider used for RPC transport be conformant to the requirements of [RFC5042] in order to satisfy these protections.
追加の考慮事項は、RDMA輸送自体によってローカルメモリの整合性とプライバシーの保護です。 RPCによるRDMAを使用すると、システムメモリの内容に、またはユーザーのプロセスが所有しているメモリへの任意の脆弱性を導入してはなりません。これらの保護は、RDMA層の仕様、具体的には、彼らのセキュリティモデルによって提供されています。 RPCの輸送のために使用される任意のRDMAプロバイダがこれらの保護を満たすために[RFC5042]の要件に適合することが要求されます。
Once delivered securely by the RDMA provider, any RDMA-exposed addresses will contain only RPC payloads in the chunk lists, transferred under the protection of RPCSEC_GSS integrity and privacy. By these means, the data will be protected end-to-end, as required by the RPC layer security model.
一度RDMAプロバイダによって安全に配信、任意のRDMA-暴露アドレスはRPCSEC_GSSの整合性とプライバシーの保護の下で転送チャンクリスト内の唯一のRPCペイロードを、含まれています。 RPC層のセキュリティモデルで必要とされるこれらの手段によって、データは、エンド・ツー・エンドの保護されます。
Where upper-layer protocols choose to supply results to the requester via read chunks, a server resource deficit can arise if the client does not promptly acknowledge their status via the RDMA_DONE message. This can potentially lead to a denial-of-service situation, with a single client unfairly (and unnecessarily) consuming server RDMA resources. Servers for such upper-layer protocols MUST protect against this situation, originating from one or many clients. For example, a time-based window of buffer availability may be offered, if the client fails to obtain the data within the window, it will simply retry using ordinary RPC retry semantics. Or, a more severe method would be for the server to simply close the client's RDMA connection, freeing the RDMA resources and allowing the server to reclaim them.
上位層プロトコルは、読み取りチャンクを経由して依頼者に結果を供給することを選択した場合は、クライアントが速やかにRDMA_DONEメッセージを介して自分の地位を認めていない場合は、サーバーのリソース不足が発生する可能性があります。これは、潜在的にサーバーのRDMAリソースを消費不当に（不必要に）単一のクライアントで、サービス拒否の状況につながることができます。こうした上位層プロトコルのためのサーバは、一つまたは複数のクライアントから発信、このような状況から保護しなければなりません。例えば、バッファのアベイラビリティの時間ベースのウィンドウは、クライアントは、ウィンドウ内のデータを取得するために失敗した場合、それは単に普通のRPC再試行のセマンティクスを使用して再試行しますが、提供されることがあります。または、より深刻な方法は、RDMAのリソースを解放し、サーバーがそれらを再利用することができ、単にクライアントのRDMA接続を閉じるには、サーバーのためになります。
A fairer and more useful method is provided by the protocol itself. The server MAY use the rdma_credit value to limit the number of outstanding requests for each client. By including the number of outstanding RDMA_DONE completions in the computation of available client credits, the server can limit its exposure to each client, and therefore provide uninterrupted service as its resources permit.
公平より有用な方法は、プロトコル自体によって提供されます。サーバーは、クライアントごとに未処理の要求の数を制限するrdma_credit値を使用するかもしれません。使用可能なクライアントクレジットの計算に優れRDMA_DONE完了数を含むことにより、サーバは、各クライアントに対するエクスポージャーを制限するため、その資源の許す限り中断のないサービスを提供することができます。
However, the server must ensure that it does not decrease the credit count to zero with this method, since the RDMA_DONE message is not acknowledged. If the credit count were to drop to zero solely due to outstanding RDMA_DONE messages, the client would deadlock since it would never obtain a new credit with which to continue. Therefore, if the server adjusts credits to zero for outstanding RDMA_DONE, it MUST withhold its reply to at least one message in order to provide the next credit. The time-based window (or any other appropriate method) SHOULD be used by the server to recover resources in the event that the client never returns.
ただし、サーバはRDMA_DONEメッセージが確認されていないので、それは、この方法でゼロにクレジット数を減少させないようにする必要があります。クレジットカウントが起因する優れたRDMA_DONEメッセージだけにゼロに低下した場合、クライアントは、それが継続するとの新しいクレジットを取得することはないので、デッドロックです。サーバーは、優れたRDMA_DONEゼロにクレジットを調整した場合ので、それは次のクレジットを提供するために、少なくとも1つのメッセージへの返信を保留しなければなりません。時間ベースのウィンドウ（または任意の他の適切な方法）は、クライアントが返すことはありませんイベント内のリソースを回復するために、サーバによって使用されるべきです。
The Connection Configuration Protocol, when used, MUST be protected by an appropriate RPC security flavor, to ensure it is not attacked in the process of initiating an RPC/RDMA connection.
接続構成プロトコルは、使用された場合、それはRPC / RDMA接続を開始する過程で攻撃されていないことを確認するために、適切なRPCセキュリティ風味で保護する必要があります。
Three new assignments are specified by this document:
三つの新しい割り当ては、この文書で指定されています。
- A new set of RPC "netids" for resolving RPC/RDMA services
- RPC / RDMAサービスを解決するためのRPC「netids」の新しいセット
- Optional service port assignments for upper-layer bindings
- 上位層のバインディングのためのオプションのサービスポートの割り当て
- An RPC program number assignment for the configuration protocol
- コンフィギュレーション・プロトコルのRPCプログラム番号割り当て
These assignments have been established, as below.
これらの割り当ては以下のように、確立されています。
The new RPC transport has been assigned an RPC "netid", which is an rpcbind [RFC1833] string used to describe the underlying protocol in order for RPC to select the appropriate transport framing, as well as the format of the service addresses and ports.
新しいRPCトランスポートは、適切なトランスポート・フレーミング、ならびにサービス・アドレスとポートの形式を選択するためにRPCために、基礎となるプロトコルを記述するために使用されるのrpcbind [RFC1833]の文字列であるRPC「NETID」が、割り当てられています。
The following "Netid" registry strings are defined for this purpose:
以下の「NETID」のレジストリ文字列は、この目的のために定義されています。
NC_RDMA "rdma" NC_RDMA6 "rdma6"
NC_RDMA "RDMA" NC_RDMA6 "rdma6"
These netids MAY be used for any RDMA network satisfying the requirements of Section 2, and able to identify service endpoints using IP port addressing, possibly through use of a translation service as described above in Section 10, "RPC Binding". The "rdma" netid is to be used when IPv4 addressing is employed by the underlying transport, and "rdma6" for IPv6 addressing.
これらnetidsは、第2の要件を満たす任意のRDMAネットワークに使用され、おそらく、「RPCバインディング」セクション10で上述したような翻訳サービスを使用することにより、アドレッシングのIPポートを使用して、サービス・エンドポイントを識別することができるかもしれません。 「RDMA」NETIDは、IPv4アドレッシングをIPv6アドレスのための基礎となるトランスポートによって使用され、「rdma6」されるときに使用されます。
The netid assignment policy and registry are defined in [RFC5665].
NETID割り当てポリシーとレジストリは[RFC5665]で定義されています。
As a new RPC transport, this protocol has no effect on RPC program numbers or existing registered port numbers. However, new port numbers MAY be registered for use by RPC/RDMA-enabled services, as appropriate to the new networks over which the services will operate.
新しいRPCトランスポートとして、このプロトコルは、RPCプログラム番号または既存の登録されているポート番号には影響しません。しかし、新しいポート番号はサービスが動作する上で新しいネットワークに応じて、RPC / RDMA対応のサービスで使用するために登録することも可能です。
For example, the NFS/RDMA service defined in [RFC5667] has been assigned the port 20049, in the IANA registry:
例えば、[RFC5667]で定義されたNFS / RDMAサービスは、IANAレジストリに、ポート20049が割り当てられています。
nfsrdma 20049/tcp Network File System (NFS) over RDMA nfsrdma 20049/udp Network File System (NFS) over RDMA nfsrdma 20049/sctp Network File System (NFS) over RDMA
RDMA経由のRDMA nfsrdma 20049 / SCTPネットワークファイルシステム（NFS）を超えるRDMAのnfsrdma 20049 / udpのネットワークファイルシステム（NFS）を超えるnfsrdma 20049 / tcpのネットワークファイルシステム（NFS）
The OPTIONAL Connection Configuration Protocol described herein requires an RPC program number assignment. The value "100417" has been assigned:
本明細書中に記載のオプションの接続構成プロトコルは、RPCプログラム番号の割り当てが必要です。値が「100417」が割り当てられています。
rdmaconfig 100417 rpc.rdmaconfig
100417 rpc.rdmaconfigをrdmaconfig
The RPC program number assignment policy and registry are defined in [RFC5531].
RPCプログラム番号の割り当てポリシーとレジストリは[RFC5531]で定義されています。
The authors wish to thank Rob Thurlow, John Howard, Chet Juszczak, Alex Chiu, Peter Staubach, Dave Noveck, Brian Pawlowski, Steve Kleiman, Mike Eisler, Mark Wittle, Shantanu Mehendale, David Robinson, and Mallikarjun Chadalapaka for their contributions to this document.
作者はこのドキュメントへの貢献のためにロブ・Thurlow、ジョン・ハワード、チェットJuszczak、アレックス・チウ、ピーター・ストーバック、デイブNoveck、ブライアン・ポロウスキー、スティーブ・クレイマン、マイク・アイスラー、マーク・Wittle、シャンタヌMehendale、デビッド・ロビンソン、そしてMallikarjun Chadalapaka感謝したいです。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[RFC1833]スリニバサン、R.、 "ONC RPCバージョン2のプロトコルのバインド"、RFC 1833、1995年8月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]アイスラー、M.、チウ、A.、およびL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506]アイスラー、M.、エド、 "XDR：外部データ表現標準"。、STD 67、RFC 4506、2006年5月。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RFC5042]ピンカートン、J.およびE. Deleganes、 "直接データ配置プロトコル（DDP）/リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ"、RFC 5042、2007年10月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009.
[RFC5403]アイスラー、M.、 "RPCSEC_GSSバージョン2"、RFC 5403、2009年2月。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009.
[RFC5531] Thurlow、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 5531、2009年5月。
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC 5660, October 2009.
[RFC5660]ウィリアムズ、N.、 "IPsecのチャンネル：接続ラッチ"、RFC 5660、2009年10月。
[RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", RFC 5665, January 2010.
[RFC5665]アイスラー、M.、RFC 5665、2010年1月 "リモートプロシージャコール（RPC）のネットワーク識別子とユニバーサルアドレス形式用IANAの考慮事項"。
[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094]サン・マイクロシステムズ、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月を。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813]キャラハン、B.、ポロウスキー、B.、およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[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.、メッツラー、B.、Culley、P.、Hilland、J.、およびD.ガルシア、 "リモートダイレクトメモリアクセスプロトコル仕様"、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]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[RFC5532] Talpey, T. and C. Juszczak, "Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement", RFC 5532, May 2009.
[RFC5532] Talpey、T.とC. Juszczak、 "ネットワークファイルシステム（NFS）リモートダイレクトメモリアクセス（RDMA）問題文"、RFC 5532、2009年5月。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5661] Shepler、S.、エド。、アイスラー、M.、エド。、およびD. Noveck、エド。、 "ネットワークファイルシステムバージョン4マイナーバージョン1つのプロトコル"、RFC 5661、2010年1月。
[RFC5667] Talpey, T. and B. Callaghan, "Network File System (NFS) Direct Data Placement", RFC 5667, January 2010.
[RFC5667] Talpey、T.とB.キャラハン、 "ネットワークファイルシステム（NFS）直接データ配置"、RFC 5667、2010年1月。
[IB] InfiniBand Trade Association, InfiniBand Architecture Specifications, available from http://www.infinibandta.org.
[IB]インフィニバンド展覧会、http://www.infinibandta.orgから入手したInfiniBandアーキテクチャ仕様、。
[IBPORT] InfiniBand Trade Association, "IP Addressing Annex", available from http://www.infinibandta.org.
[IBPORT] http://www.infinibandta.orgから入手できるインフィニバンド展覧会、 "IPアドレス指定別館"、。
Authors' Addresses
著者のアドレス
Tom Talpey 170 Whitman St. Stow, MA 01775 USA
トムTalpey 170ホイットマンセントストウ、MA 01775 USA
EMail: tmtalpey@gmail.com
メールアドレス：tmtalpey@gmail.com
Brent Callaghan Apple Computer, Inc. MS: 302-4K 2 Infinite Loop Cupertino, CA 95014 USA
ブレントキャラハンされたApple Computer、Inc. MS：302-4K 2無限ループクパチーノ、CA 95014 USA
EMail: brentc@apple.com
メールアドレス：brentc@apple.com