[要約] RFC 5666は、リモートプロシージャコールのためのリモートダイレクトメモリアクセストランスポートに関するものであり、RDMAを使用して高性能なネットワーク通信を実現することを目的としています。
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.
このドキュメントでは、リモートの直接メモリアクセス（RDMA）を提供するプロトコルで、リモートプロシージャコール（RPC）の新しい輸送機関として説明しています。RDMAトランスポートバインディングは、高速ネットワーク上の効率的なバルクデータ輸送の利点を伝え、RPCアプリケーションに最小限の変更を提供し、アプリケーションRPCプロトコル、またはRPCプロトコル自体の必要な改訂を提供します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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データストリームは、各タイプのトランスポートで異なって伝えられます。UDPでは、RPCメッセージはデータグラム内にカプセル化されますが、TCPバイトストリームでは、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のみの動作とは異なり、新しいセマンティクスを提示します。UDPのようなメッセージの描写を保持しながら、TCPのような信頼できるシーケンスされたデータ転送も提供します。また、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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操作を介して移動されたすべてのデータは、宛先の登録メモリに居住しています。このプロトコルは、登録されたメモリの各セグメントは、32ビット以下のステアリングタグと、長さが最大64ビットのメモリアドレスで識別される必要があると想定しています。
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 Send 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 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書き込みRDMAプロバイダーは、RDMA書き込み操作をサポートして、レシーバーのバッファにデータを直接配置します。RDMAの書き込みは送信者によって開始され、完成が送信者で通知されます。受信機には完了は示されていません。送信者は、ステアリングタグ、メモリアドレス、およびリモート宛先バッファの長さを使用します。RDMAの書き込みは、必ずしも互いに注文されるわけではありませんが、RDMA送信に関して注文されます。レシーバーで得られたその後のRDMA送信完了は、以前のRDMA書き込みデータが受信機のメモリに正常に配置されたことを保証します。
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プロトコル（IWARP）[RFC5040、RFC5041]、またはInfiniband [IB]など、RDMAトランスポートに容易に運ばれます。
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-Over-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-over-RDMAヘッダーを送信することから始まります。通常、通話または返信メッセージが追加されるか、少なくともその一部が追加されます。RDMA送信を介して送信される可能性のあるもののサイズはレシーバーの事前ポストバッファーのサイズによって制限されるため、RPCオーバーRDMAトランスポートは、必要に応じてRDMA送信によって転送される量を減らすための多くの方法を提供します。、RDMA読み取りと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-Over-RDMAフレーミングは、基礎となるRDMAプロトコル自体が定義されたRPCフレーミング（TCPなど）を備えたプロトコルの上に階層化される場合がありますが、RPC/RDMAアソシエーションの上で使用する場合、他のすべてのRPCフレーミング（TCPレコードマーキングなど）に取って代わります（TCPなど）。ただし、上層層交換を介してRDMAの使用を交渉する過程で、RPC/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メッセージは非常に短いです。たとえば、NFSバージョン3 getATTRリクエストは、20バイトのRPCヘッダーに加えて、32バイトのファイルハンドル引数と4バイトの長さの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-Over-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コールまたは返信で非常に大きなデータのチャンクを転送できるRPC手順があり、RDMA送信の一部としてそれらを転送しようとした場合に最大送信サイズを超えます。これらの大きなチャンクは、通常、キロバイトからメガバイト以上まで及びます。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コールバックはNFSV4クライアントによって処理され、RPCサーバーとして機能します。クレジットディスカッションはどちらの場合も等しく適用されます。）
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-Over-RDMAヘッダーの単純なリクエスト/助成金プロトコルとして実装されます。RPCコールメッセージのRPC-Over-RDMAヘッダーには、RPCサーバーの要求されたクレジット値が含まれています。これは、予想されるニーズに合わせて発信者によって動的に調整される場合があります。RPC ReplyメッセージのRPC-Over-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エラーを返す可能性があります。また、Never-Zero要件は、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サーバーの現在のフロー制御制限は、送信順序付けプロパティから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の進行中のRDMA読み取り操作の制限など、追加のフロー制御制限が課される場合があります。これらの操作はこのプロトコルの範囲外であるため、対処されておらず、他のレイヤーによって提供される必要があります。たとえば、単純な上層層RPC消費者は、単一発行のRDMA読み取りリクエストを実行する可能性がありますが、より洗練されたマルチスレッドRPC消費者は、そのような操作の最初の、最初の（FIFO）キューに独自の独自のキューを実装する可能性があります。これらの値を交渉できるプロトコルの実装の可能性の詳細については、このドキュメントのセクション6「接続構成プロトコル」、または[RFC5661]を参照してください。
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.
意味的に言えば、プロトコルには、読み取りまたは書き込みチャンクによって表される場合としない場合があるデータ型に関する制限はありません。ただし、実際には、効率の考慮事項は、特定のデータ型は一般に「塊」ではないという結論につながります。通常、実質的なサイズに達する可能性のある不透明で集約されたデータ型のみが適格であると見なされます。今日のハードウェアを使用すると、このサイズはキロバイト以上かもしれません。ただし、すべてのオブジェクトは、特定のメッセージでチャンキングするために選択される場合があります。
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-Over-RDMAプロトコルでは指定されていません。相互運用可能な仕様を提供するには、各上層層によって塊の適格性基準を決定する必要があります。NFSプロトコルファミリーの理論的根拠を持つそのような例の1つは、[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レイヤーが「その場で」メモリの高価な登録と解体を実行するためにRPCレイヤーを必要とするか、返信メッセージでRDMAチャンクを使用し、結果として追加のハンドシェーキングを使用する必要があるため、非効率につながる可能性があります。RPC-Over-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ストリーム要素のデータ部分のみを指します。特に、カウントされたフィールド（たとえば、「<>」エンコード）の場合、フィールドの一部としてエンコードされたバイトカウントは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.
ゼロベースのオフセットスキームは多くのRDMA実装で利用できますが、RPCによる使用には、各読み取りまたは書き込みチャンクの個別の登録が必要です。このような多くの実装では、これは重要なオーバーヘッドになる可能性があります。各チャンクでオフセットを提供することにより、多くの事前登録または地域ベースの登録を容易にサポートでき、単一のユニバーサルチャンク表現を使用することにより、RPC RDMAプロトコルの実装が最も一般的な形式に簡素化されます。
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 Marshalingが完了すると、チャンクリストが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.
したがって、読み取りチャンクは読み取りチャンクリストに単一の配列としてエンコードされ、各エントリはその（既知の）サイズとその引数または結果の位置でタグ付けされます。書き込みチャンクは、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デコードプロセスは、XDRストリームからRPCクライアントまたはサーバーアプリケーションが提供するデータ構造にデータを移動します。宛先データ構造の要素がバッファまたは文字列である場合、RPCアプリケーションはストレージを事前にアロッカ化してデータを受信するか、文字列またはバッファフィールドをnullしたままにし、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トランスポートからのメッセージをデコードすると、ReceiverはRPC-Over-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レシーバー（クライアント）はRDMA_DONEメッセージ（セクション3.8で説明）を発行して、ソースバッファーが解放されることをピア（サーバー）に通知する必要があります。
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サーバーは、Chunk Listエントリで参照されているメモリに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.
デコードされた各結果は、書き込みチャンクリストに1つのエントリを消費し、これはRDMAセグメントの配列で構成されます。したがって、長さは、対応するリストエントリを含むすべてのセグメントのすべての返品された長さの合計です。各リストエントリがデコードされると、エントリ全体が消費されます。
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バイト境界で次の要素を開始するようにパッドでパッドされますストリーム。TCPまたはRDMAインラインエンコードの場合、輸送固有のフレーミングは、メッセージの開始時からXDRストリームの要素の相対的なオフセットがデコード中のXDR位置を決定するという事実に依存しているため、この最小限のオーバーヘッドが必要です。
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.
たとえば、NFSがファイルの最後や直接I/Oの状況で遭遇したデータについて書いている場合、RDMA内のこれらのラウンドアップがチャンクを読み取ります。ラウンドアップバイトは実際には作成されているデータバッファーには存在しないため、これらのバイトのメモリは、追加のメモリ登録セグメントとして、または追加のチャンクとして、非連続バッファーから得られます。これらの操作のオーバーヘッドは、それらをマーシャルする送信者の両方にとって重要であり、それらを転送するレシーバーにさらに高くなる可能性があります。したがって、送信者は、可能な限り、個々の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ストリームからのラウンドアップデータを排除するために、送信者に追加データの露出がないことに注意してください。データは文字通り転送されるものではありません。
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: An RPC with write chunks in the call message:
これらのデータ移動方法は、単一のRPC内の組み合わせで発生する可能性があります。たとえば、RPCコールには、RDMA読み取りを介してサーバーに転送されるいくつかの大きなチャンクとともに、いくつかのインラインデータが含まれる場合があります。その呼び出しへの返信には、サーバーRDMAがクライアントに書き戻す結果のチャンクがある場合があります。次のプロトコルインタラクションは、これらのメソッドを使用してRPCメッセージデータを移動する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注文は、クライアントのRPC返信処理の前に、RDMA書き込み操作のすべてのデータがメモリに配置されていることを保証します。
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.
完了したメッセージがRPCサーバーでクレジットを消費することに注意することが重要です。RPCサーバーは、クライアントに十分なクレジットを提供して、デッドロックなしで完了したメッセージを送信できるようにします（未払いのクレジットカウントをゼロに駆り立てる）。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.
パディングの効果は、以下に、以前のバイト（下の図の「xxx」）の以前のバイトを示しています。その後、4つの長さバイト（「LLLL」）で構成される不透明フィールドに続いて、データバイト（「DDD」）が続きます。RDMA送信の受信機には、2つのチェーンズ受信バッファーが投稿されています。パディングがなければ、不透明なデータは2つのバッファーに分割されます。最初のデータバイトの前にパディングバイト（「PPP」）を追加すると、2番目のバッファーにデータを正しく整列させることができます。
Buffer 1 Buffer 2
Unpadded -------------- --------------
XXXXXXXLLLLDDDDDDDDDDDDDD ---> XXXXXXXLLLLDDD DDDDDDDDDDD
xxxxxxlllllddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
Padded
パッド付き
XXXXXXXLLLLpppDDDDDDDDDDDDDD ---> XXXXXXXLLLLppp DDDDDDDDDDDDDD
XXXXXXLLLLLPPPDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
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トランスポートエンコード内で完全に実装されています。パディングが適用される場合、2つの値がピアに渡されます。「RDMA_Align」、パディング値は使用されています。たとえば、サーバーがチェーンズ4 kb受信バッファーを使用している場合、最大（4 kb -1）のパディングバイトを使用して、データの調整を実現できます。ピアのXDRルーチンは、不透明な値を解読するときにこれらの値を参照する必要があります。デコードされた長さがRDMA_THRESHを超える場合、XDRデコードは、RDMA_Alignと現在の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-Over-RDMAヘッダーを使用してRDMAトランスポート全体で伝えられます。RPC-over-RDMAヘッダーには、RDMAフロー制御クレジット、パディングパラメーター、およびRDMAの読み取りおよび書き込み操作を介した直接的なデータ配置を提供するアドレスのリストのデータが含まれています。RPCメッセージ自体のレイアウトは、RDMA読み取り操作によって移動される大きなデータチャンクを除外する可能性を除き、[RFC5531]で説明されているものから変化しません。RPCメッセージ（RPC-Over-RDMAヘッダーとともに）が投稿されたバッファーには長すぎる場合（大きなチャンクが削除された後でも）、RPCメッセージ全体をチャンクとして個別に移動し、RPCだけを残すことができます-RDMA送信のオーバー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-Over-RDMAヘッダーは、常に存在し、RDMA固有のフロー制御を含むRDMA相互作用を制御する4つの32ビットフィールドから始まります。その後、これらの後に、送信の種類に応じて存在する場合とそうでない場合があるチャンクリストやパディングなどの多くのアイテムが続きます。常に存在する4つのフィールドは次のとおりです。
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）。RPCコールと返信用に生成されたXID。メッセージの先頭に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メッセージプロトコルのこのバージョンは1です。RPCRDMAメッセージの形式が変更された場合は、バージョン番号を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コールは、現在付与されている制限を超えて送信されないでください。
4. Message type.
4. メッセージタイプ。
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メッセージがないことを示します。この場合、Chunkリストは、RDMAの読み取りまたは書き込みを使用して適切なメッセージを転送できるようにするための情報を提供するため、RPC-Over-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のメッセージの場合、読み取りおよび書き込みチャンクリストが続きます。読み取りチャンクリストがnull（ゼロの32ビットワード）の場合、別々に転送するチャンクはなく、RPCメッセージ全体が続きます。非ヌルの場合、それは読み取りチャンクリストエントリのXDRエンコードされたシーケンスの始まりです。書き込みチャンクリストが非ヌルの場合、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 Replyメッセージ本文が続く必要があります。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.
2種類のエラーが定義されています。バージョンの不一致と無効なチャンク形式です。ピアがサポートしていないRPC-Over-RDMAヘッダーバージョンを検出すると（現在、このドキュメントはバージョン1のみを定義しています）、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 };
enum 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が以前に1つ以上の適切なサイズのバッファを投稿したことを要求されています。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の読み取りや書き込みのような大きなメッセージでさえ、メッセージからチャンクが削除されると、非常に小さくなります。ただし、非常に大きなバッファーを要求する大きなメッセージがあり、バッファの内容が充電可能な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.
比較的簡単な方法の1つは、クライアントにRPCサーバーの投稿されたバッファサイズを超えた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位置がゼロの最初の読み取りチャンクリストエントリを見つけた場合、登録されたバッファーを割り当て、RDMAが長いRPCメッセージの読み取りを発行します。その後、受信機はXDRに進み、RPCメッセージを送信データとインラインで受信したかのように解読します。さらにデコードすると、追加の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
RDMA読み取りを介して返された長い返信があるRPC
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
RDMA書き込みを介して、長い返信があるRPCが返されました
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クライアントとサーバーの両方にとって非常に効率的で便利です。それらの使用は、NFS Readdirなどの適格なRPC操作に奨励されています。これは、RDMA読み取りおよび完了したメッセージ[RFC5667]の結果または使用中の広範なチャンク管理を必要とするものです。
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 kbのサイズで少なくとも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の読み取り操作が同時に発行された場合、接続損失または最適ではないフロー制御が生じる可能性があります。したがって、値は常に観察する必要があります。ピアの価値は平等である必要はありません。ゼロの場合、ピアは、転送が不可能であるため、満足するために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;
typedef unsigned int 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-Over-RDMAトランスポートのデフォルトの動作は、すべてのトランザクションでこれらのチャンクを登録および登録することです。ただし、これはプロトコルの制限ではありません - 既存のローカルRPC APIのみです。APIは、RPC_CONTROL（3）のような関数を介して簡単に拡張され、デフォルトの動作を変更して、アプリケーションがRPCが提供する登録メモリアロケーターを介してメモリ登録を制御する責任を引き受けることができます。
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）、およびInfiniband Linkレイヤーはすべて、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]サービスに登録します。（UDPまたはTCPの場合、NFSのサービスアドレスは通常ポート2049です。）このポリシーはRDMA相互接続と違いはありませんが、RPCフレーミングを使用する各上層層結合に適したポート番号の割り当てが必要になる場合があります。ここで定義されています。
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.
IWARP [RFC5040、RFC5041]トランスポートの上にマッピングされた場合、TCPおよび/またはSCTPの階層化によりIPポートアドレス指定を使用すると、ポートマッピングは些細なものであり、接続プロセスでポートを発行するだけです。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.
グループ識別子（GID）ベースのサービスエンドポイントネーミングスキームを使用するInfiniband [Ib]の上にマッピングされた場合、翻訳を使用する必要があります。そのような翻訳の1つは、IPポートアドレスをInfinibandネットワークに翻訳するのに適したAnnex [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.
1つの可能性は、ここで定義されているNetID（またはNetID）の下で、上層サーバーにマッピングされたIPポートをRPCBINDサービスに登録することです。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インターコネクトにサーバーのポートマッパーを登録させることです。（UDPまたはTCPでは、これはポート111に対応します。）クライアントは、このサービスアドレスに接続し、ポートマッププロトコルを使用して、プログラム番号、たとえばIWARPポート番号、またはInfiniband GIDに応じてサービスアドレスを取得できます。
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サービスは、そのようなインフィニバンドファブリックの上で操作する場合、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.
セクション12の「IANAの考慮事項」では、この仕様では、IWARP [RFC5040、RFC5041]および（適切なポート翻訳サービスが利用可能な場合）Infiniband [IB]の上の上層の登録に使用される2つの新しい「NetID」値を定義します。追加のRDMA対応ネットワークは、独自のNetIDを定義する場合があります。または、ポート翻訳を提供する場合は、ここで定義されているものを共有できます。
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]およびIPSECチャネル接続ラッチング[RFC5660]と併せて[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トランスポートに使用される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メッセージを介してステータスを迅速に確認しない場合、サーバーリソースの赤字が発生する可能性があります。これにより、1人のクライアントが不当に（そして不必要に）サーバーRDMAリソースを消費することで、サービス拒否の状況につながる可能性があります。このような上層層プロトコルのサーバーは、1つまたは多くのクライアントに由来するこの状況から保護する必要があります。たとえば、バッファの可用性の時間ベースのウィンドウが提供される場合があります。クライアントがウィンドウ内のデータを取得できない場合、通常の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:
このドキュメントでは、3つの新しい課題が指定されています。
- 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.
これらのNetIDは、セクション2の要件を満たすRDMAネットワークに使用され、おそらくセクション10「RPCバインディング」で説明した翻訳サービスを使用して、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
NFSRDMA 20049/TCPネットワークファイルシステム（NFS）RDMA NFSRDMA 20049/UDPネットワークファイルシステム（NFS）RDMA NFSRDMA 20049/SCTPネットワークファイルシステム（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
rdmaconfig 100417 rpc.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.
著者は、ロブ・サーロー、ジョン・ハワード、チェット・ジュシュザック、アレックス・チウ、ピーター・スタウバッハ、デイブ・ノヴェック、ブライアン・ポーロウスキ、スティーブ・クレイマン、マイク・アイスラー、マーク・ウィットル、シャンタヌ・メヘンデール、デビッド・ロビンソン、マリカルジュン・チャダラパカに感謝します。。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[RFC1833] Srinivasan、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] Eisler、M.、Chiu、A。、およびL. Ling、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506] Eisler、M.、ed。、「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] Pinkerton、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] Eisler、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] Eisler、M。、「リモートプロシージャコール（RPC）ネットワーク識別子とユニバーサルアドレス形式に関するIANAの考慮事項」、RFC 5665、2010年1月。
[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094] Sun Microsystems、「NFS：ネットワークファイルシステムプロトコル仕様」、RFC 1094、1989年3月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、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.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「リモートダイレクトメモリアクセスプロトコル仕様」、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「信頼できる輸送を介した直接データ配置」、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.、ed。、Eisler、M.、ed。、およびD. Noveck、ed。、「ネットワークファイルシステムバージョン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. Callaghan、「ネットワークファイルシステム（NFS）ダイレクトデータ配置」、RFC 5667、2010年1月。
[IB] InfiniBand Trade Association, InfiniBand Architecture Specifications, available from http://www.infinibandta.org.
[IB] Infiniband Trade Association、Infiniband Architectureの仕様、http：//www.infinibandta.orgから入手可能。
[IBPORT] InfiniBand Trade Association, "IP Addressing Annex", available from http://www.infinibandta.org.
[Ibport] Infiniband Trade Association、http://www.infinibandta.orgから入手可能。
Authors' Addresses
著者のアドレス
Tom Talpey 170 Whitman St. Stow, MA 01775 USA
Tom Talpey 170ホイットマンセントストウ、マサチューセッツ州01775 USA
EMail: tmtalpey@gmail.com
Brent Callaghan Apple Computer, Inc. MS: 302-4K 2 Infinite Loop Cupertino, CA 95014 USA
Brent Callaghan Apple Computer、Inc。MS：302-4K 2 Infinite Loop Cupertino、CA 95014 USA
EMail: brentc@apple.com