【RDMA】16. RDMA之DDP(Direct Data Placement)
【RDMA】RDMA 學習資料總目錄_bandaoyu的筆記-CSDN博客SavirRDMA 分享1. RDMA概述https://blog.csdn.net/bandaoyu/article/details/112859853https://zhuanlan.zhihu.com/p/1388747382. 比較基于Socket與RDMA的通信https://blog.csdn.net/bandaoyu/article/details/1128613993. RDMA基本元素和編程基礎https://blog.csdn.net/bandaoyu/article/de.https://blog.csdn.net/bandaoyu/article/details/120485737
概述
傳統TCP/IP協議棧中，網卡先將數據DMA拷貝到內核空間的緩沖區，再由CPU將經過協議棧處理的數據拷貝到用戶空間。
那么為什么不能放用戶空間呢？網卡知道放到內核空間的哪個位置，是因為協議棧已經提前告知網卡緩沖區的地址。
iWARP是在現有TCP/IP協議棧基礎上實現RDMA技術，TCP/IP協議早已形成標準，不可能修改現有協議字段，增加DDP，既在TCP基礎（或者是SCTP）上加一層，DDP的報文頭中，攜帶了能夠幫助網卡識別用戶應用程序緩沖區的位置信息。
正文
原文：16. RDMA之DDP(Direct Data Placement) - 知乎
本文歡迎轉載，轉載請注明出處。
最近在研究iWARP的實現，就先寫一下它的各層協議吧，iWARP的綜述篇可能會晚于各層協議完成。
Direct Data Placement，簡稱為DDP，是iWARP協議棧的核心成員。DDP協議在TCP/SCTP之上實現了了RDMA技術中的零拷貝，即在通信過程中，使接收端的硬件可以直接把收到的數據放置到用戶空間的Buffer，從而避免多次在Buffer間的拷貝數據對CPU產生的開銷。
本文的主要目的是幫助大家快速且容易的了解DDP，內容主要是基于RFC4296和RFC 5041完成的，更多細節請參考原文。閱讀本文前建議溫習一下本專欄的基礎概念篇。如有疑問或有錯誤需要更正，歡迎在評論區留言。
概述
我們先來看一下DDP試圖解決什么樣的問題：
每次數據在內存中的拷貝，都需要CPU一邊通過總線從內存中讀取數據，一邊通過總線向內存中的另外一處寫入數據。所以至少需要占用2倍于網卡帶寬的CPU負載和3倍于網卡帶寬的內存帶寬（設備DMA寫入一次，CPU讀寫各一次），因此有必要實現零拷貝技術來解放CPU和內存的帶寬。
同一份數據，被DMA拷貝了一次（網卡-->驅動內存），CPU拷貝了一次（驅動內存-->應用內存）
Infiniband技術的RDMA Write/Read操作已經有了零拷貝的實現，是通過在報文中攜帶VA和R_Key的方式來實現的。接收端的硬件通過接收報文中的R_Key找到內存的VA-PA（虛擬地址-物理地址）轉換表，然后把報文中的VA轉換為PA，最后直接把Payload放到內存的對應位置中。
RDMA Extended Transport Header (RETH)
然而Infiniband使用的是全新設計的協議棧，硬件無法與現有網絡兼容。之前我們講過，如果用戶想要從以太網切換到IB，那么需要把網卡、交換機、路由器和光纜等設備全部更換，將是很大的一筆開銷。
DMA技術在以太網卡中早已普及，即網卡收到消息后，可以在CPU不參與數據拷貝的情況下，就可以直接將數據放到指定內存區域中。
在傳統的TCP/IP協議棧中，網卡要先將數據通過DMA拷貝到內核空間的緩沖區中，再由CPU將經過協議棧處理的數據拷貝到用戶空間。
既然網卡可以直接將數據放到內核空間，那么為什么不能放用戶空間呢？本質上只是地址不同罷了，之所以網卡知道放到內核空間的哪個位置，是因為協議棧已經提前告知網卡緩沖區的地址。同理，只要網卡有辦法獲取到用戶空間內存地址對應的物理地址，就可以直接把數據放到用戶空間了，也就是實現了不需要CPU參與的零拷貝：
iWARP的目標是在現有TCP/IP協議棧基礎上實現RDMA技術，而DDP這一層的主要功能就是實現零拷貝。因為TCP/IP協議早已形成標準，不可能修改現有協議字段，所以DDP實現零拷貝的方案就是在TCP基礎（或者是SCTP）上加一層，作為其負載。而DDP的報文頭中，攜帶了能夠幫助網卡識別用戶應用程序緩沖區的位置信息。
DDP作為中間層，本身是不限制上層和下層協議的。只是在iWARP協議棧中，DDP向上為RDMAP服務，向下承接TCP（中間有一層很“薄”的MPA，我們在后文介紹）或者SCTP：
iWARP協議棧
術語
為了方便后文的講解，我們先來對一些屬術語進行說明。
ULP
Upper Layer Protocol，上層協議。顧名思義，就是在DDP協議之上的其他協議，最常見的是iWARP協議棧中的RDMAP層。
RDMA Consortium?和?IBTA?主導了RDMA，RDMAC是IETF的一個補充，它主要定義的是iWRAP和iSER，IBTA是infiniband的全部標準制定者，并補充了RoCE v1 v2的標準化。應用和RNIC之間的傳輸接口層（software transport interface）被稱為Verbs。IBTA解釋了RDMA傳輸過程中應具備的特性行為，而并沒有規定Verbs的具體接口和數據結構原型。這部分工作由另一個組織OFA（Open Fabric Alliance）來完成，OFA提供了RDMA傳輸的一系列Verbs API。OFA開發出了OFED（Open Fabric Enterprise Distribution）協議棧，支持多種RDMA傳輸層協議。
OFED中除了提供向下與RNIC基本的隊列消息服務，向上還提供了ULP（Upper Layer Protocols），通過ULPs，上層應用不需要直接到Verbs API對接，而是借助于ULP與應用對接，常見的應用不需要做修改，就可以跑在RDMA傳輸層上。
LLP
Lower Layer Protocol，下層協議。跟ULP的含義相反，指的是DDP層之下的協議，最常見的是TCP和SCTP。
RNIC
指的是支持RDMA技術的網卡（RDMA enbled Network Interface Controller）。iWARP協議中一般稱網卡為RNIC，而Infiniband和RoCE一般稱為HCA（Host Channel Adapter）。
Node
指的是網絡中的物理設備，即網絡中的一個節點。一個Node可以包含多個RNIC。
Peer
我們將相互之間建立了連接的兩個支持DDP協議的實體稱為Peer，這個實體一般指的是用戶應用程序。Peer一定是成對存在的，鏈路兩端分別稱為Local Peer和Remote Peer。
Node/Peer是兩個不同層級的概念，Node是物理實體，Peer是協議實體。一個Node上可以有多個Peer。
DDP Message
來自于ULP的數據，因為LLP的限制，這個Message可能會被切分成多個塊，每個塊都是一個DDP Segment。這些Segment中的數據最終會在接收端被提取出來還原成原來的Message。
DDP Segment
Message切分后產生的多個DDP分段。每個Segment都包含Header和Payload部分。Header部分包含的是控制信息，Payload就是實際的數據。
它們之間的關系如下圖所示：
Data Sink
指接收數據的Peer，而不是接收DDP消息的Peer。比如在上層是RDMAP時，RDMA Read操作的發起方是最終接收數據的一方，所以是Data Sink；如果是RDMA Write操作，響應方是數據的接受者，所以它是Data Sink。
Data Source
指發送數據的Peer。
Data Sink和Data Source
Steering Tag （轉向標簽）
簡稱為STag，是指向Data Sink（Data Sink）的一片內存區域的標識符。通過STag，RNIC可以找到對應的內存的物理地址，并且對其進行讀寫。這個概念跟Infiniband協議中的R_Key和L_Key很像，只不過iWARP中的通信雙方對于一片內存使用相同的STag，而沒有區分本地訪問和遠端訪問。
在注冊指定的一片內存緩沖區之后，會產生一個STag，用于本地和遠端用戶訪問這片內存。這個注冊的過程是由ULP實現的，如果ULP是RDMAP，那么這個步驟就是注冊MR的動作。注冊MR的過程中，硬件會記錄STag和內存位置的關系，然后驅動程序將STag返回給ULP。
Data Source的ULP可以將注冊MR過程中產生的STag下發給硬件，以使其能夠直接訪問本地用戶Buffer（比如post recv時下發給硬件的WR中指定的Buffer）。也可以把STag發送給對端，對端可以把這個STag攜帶在報文中，用于指定本端的一個Buffer。
Advertisement
指的是將STag等地址信息告知對端的行為。這個行為是由ULP控制的，具體發送哪些信息，以什么格式發送都由上層決定。通常在通信準備階段，Local Peer將一塊內存區域注冊到硬件，產生Stag等信息之后，將這些信息Advertise給Remote Peer。
Placement
指的是RNIC根據DDP Header的信息把收到的DDP segment的Payload放到Buffer中的行為。
Delivery
通知ULP數據已經就緒的行為，即告訴ULP數據已經組裝完畢，可以取走使用了。在一個DDP Message的所有Segment都放置完畢后，即已經在Buffer中還原出完整的數據后，DDP會通知ULP。
Buffer Model
根據數據接收端如何存放收到的數據，DDP中定義了兩種接收緩沖區的類型：
Tagged Buffer Model
還記得IB規范中描述的RDMA Write操作和Read操作嗎？Tagged Buffer Model類似于Infiniband規范中所描述的RDMA Write/Read操作。
ULP可以將STag以Socket/CM等方式發送給對端（即上文提到的Advertisement操作）。這樣Data Source就可以通過在DDP Header中攜帶STag，來指定想要寫入或者讀取的Data Sink的內存區域。Data Sink的硬件通過STag找到內存中的目的地，從而可以在CPU不參與的情況下搬移數據。
因為DDP的Message可能會被下層的協議分成多個Segment，所以每個DDP分段都要在Header中攜帶STag。另外由于每個分段可能不按順序到達對端，所以對端還需要額外的信息把這些分段拼接起來。DDP采用的方式是在Header中攜帶偏移信息TO（Tagged Offset），接收端的硬件可以通過這些偏移信息，一段一段的把每個DDP Segment的Payload放到STag指向的Buffer中的指定位置（即上文所說的Placement）。當一個消息的所有分段都被放到正確的位置之后，Message也就在接收端的內存被完整的還原了出來。
ULP并不知道從Tagged Buffer的哪個位置開始取數據，即上圖中Message 1的起始位置TO 1或者Message 2的起始位置TO 3，它們也被稱為Initial TO。ULP需要通過某種方式得到這個TO 1，根據RFC 5041中的描述，有幾種解決辦法：
- 如RDMAP協議一樣，增加一些交互邏輯，提前知會對方這個偏移。
- 固定從Buffer的起始地址開始存放數據：即通信的雙方約定好，每個消息都固定使用Initial TO = 0。
- 通過額外的方式告知：即發送Tagged DDP Message之后，緊接著發送一個Untagged DDP Message（下文介紹）來告知對端Initial TO。
Untagged Buffer Model
DDP中的Untagged Buffer Model，類似于IB規范中的Send-Recv操作中的接收方式。它并不會用STag來指定對端的特定緩沖區，這也是它被稱為“Untagged”的原因。
這種模型下，Data Sink提前準備好了一些接收隊列，這些隊列中各存放了一些接收Buffer。Data Source不會在Header中攜帶STag，而是指定了隊列號，這樣Data Sink的RNIC收到數據后，就會從指定的隊列中取出一個Buffer，把數據放到其中。不同的隊列可以用于傳遞不同的信息，比如一個隊列用來接收ULP的數據，另一個隊列用來接收ULP的控制信息。
Untagged Buffer Model同樣面臨著分段后重組的問題，所以也需要在每個Segment中攜帶偏移信息，Untagged模型下的偏移信息被稱為MO（Message Offset）。但是跟Tagged Buffer Model不同，它最終數據放到哪里是由接收端決定的，而且一個接收隊列中有很多個Buffer。而同一組消息，是不可能放到不同的Buffer中的，因此需要將一個Message的不同Segment關聯起來。DDP設計采用了隊列號QN+消息序號MSN（Message Sequence Number）的方式來指定唯一的接收Buffer，這樣一個Message的不同Segment就可以被還原到同一個緩沖區中了。
除了上面的描述之外，RFC 5041還對DDP的這兩種模型做了另外的規定：
每個Untagged Buffer只能給一個DDP Message從0開始使用，而每個Tagged Buffer都可以給多個DDP Message共享使用，并且可以從任意位置開始存放數據。在上面兩張圖中，我也體現了這個規則。
我們來總結一下Tagged和Untagged Buffer Model的差異：
| 接收Buffer | 用Tag指定使用哪個接收Buffer（發送端指定） | 按照接收順序依次放到隊列的接收緩沖區中（接收端指定） |
| 發送前準備 | 接收端ULP需要通知發送端ULP緩沖區的信息 | 不需要準備，可隨時發起（需要考慮流控） |
| 偏移 | 從tagged buffer的任意位置開始 | 只能從0開始 |
| 多DDP消息 | 允許使用同一個ULP Buffer | 需要為每個DDP消息準備一個ULP Buffer |
報文格式
下面來看一下DDP協議的報文包含哪些字段，以及它們的含義和作用。本小節是RFC 5041第4章的翻譯和再整理，建議讀者先閱讀原文以獲得更精確的描述。
大家可以從Wireshark官網獲取抓好的報文：
https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures#infiniband
建議選擇iwarp_rdma.tag.gz，因為里面包含了Tagged/Untagged Buffer Model兩種情況。
DDP Header
依據Buffer Mode的不同，DDP Header有兩種格式，但是這兩種格式有幾個公共域段：
前兩個字節是給MPA（Marker Protocol data unit Aligned framing）預留的，在iWARP協議棧中它是TCP和DDP的中間層。如果LLP是STCP，那么就不需要預留這兩個字節。我們會在以后的文章中介紹。
- T - Tagged flag: 1bit
這個標志位用來標識是哪種Buffer模型。值為1時表示Tagged Buffer Model，值為0時表示Untagged Buffer Model。硬件是依據這一個bit來決定如何解析后面的域段的。 - L - Last flag: 1bit
用于標識一個Message的最后一個Segment。上文中我們介紹過，一個DDP Message會被拆分成多個Segment，只有最后一個Segment的這個標志位會被置1。- 對于發送端來說，置了這個標志的Segment必須是在同屬于一個Message的Segment中的最后一個下發給LLP。
- 對于接收端來說，如果收到了置了此標志位的Segment，必須在同屬于一個Message的Segment的Payload都已經完成Placement和所有之前的Message都處理完畢之后通知ULP數據已經可用（Delivery）。
- Rsvd - Reserved: 4 bits
保留域段，必須為0。 - DV - DDP Version: 2 bits
DDP版本。為以后的擴展性考慮，目前只有一個DDP版本，所以恒為1。
Tagged Buffer Model
Tagged Buffer Model的Header總長度為14個字節。
- RsvdULP - Reserved for use by the ULP: 8 bits
ULP保留域段。這個域段是由ULP定義的，DDP不關心其含義，只需要保證一個Message的每個Segment的該域段保持一致和不變就可以了。在Data Sink，該域段會被原封不動的傳遞給ULP。 - STag - Steering Tag: 32 bits
前文已經介紹過，用來指定一個Data Sink的Tagged Buffer。DDP需要保證一個Message的每個Segment的該域段保持一致和不變。 - TO - Tagged Offset: 64 bits
上文也已經介紹過，用來表示Payload在Tagged Buffer中從Buffer的起始地址到最終數據的存放地址的偏移。
Untagged Buffer Model
總長度為18字節。
- RsvdULP - Reserved for use by the ULP: 40 bits
雖然跟Tagged Buffer Model中的作用相同，但是這里擴展到了5個字節，并且RFC 5041中補充了一段：
具體為什么加這句話還沒有想明白，可能跟上層有關系。
- QN - Queue Number: 32 bits
上文中介紹過，指的是Data Sink端的Untagged Buffer隊列的序號。 - MSN - Message Sequence Number: 32 bits
DDP Message的序列號。必須從1開始，每次遞增1。當到達0xFFFFFFFF之后，重新變為0。每個Message都只能對應一個Untagged Buffer，所以MSN+QN能夠唯一確定一個Untagged Buffer。 - MO - Message Offset: 32 bits
上文中介紹過，表示從QN和MSN確認的Untagged Buffer的起始位置到消息目的地址的偏移。不難想到，第一個Segment的MO一定為0。
DDP Payload
DDP Header后面緊跟的就是Payload，沒有什么需要特別注意的。
實驗
因為Wireshark提供的示例太簡單，都是不分段的DDP消息，建議大家使用支持iWARP的網卡或者使用虛擬機+Soft-iWARP跑一些更復雜的業務來做實驗。
本文接下來的實驗是通過虛擬機+Soft-iWARP實現的。iWARP和Soft-iWARP的詳情我將在以后的文章中介紹，目前僅給出簡單的配置過程。
環境配置請參考《RoCE & Soft-RoCE》這篇文章的“如何做實驗”這一章節。差異點僅在于rxe需要改為siw（Soft-iWARP）。
為了避免干擾，如果讀者的環境中已經配置了RXE，那么請使用下述命令刪除Soft-RoCE設備：
sudo rdma link delete rxe_0然后加載siw驅動：
sudo modprobe siw添加siw設備：
sudo rdma link add siw_0 type siw netdev ens33此時我們用ibv_devices就能看到新添加的siw設備了：
虛擬機兩端都配置好了之后，就可以跑perftest測試了。執行之前請先在宿主機打開wireshark，并選擇對應的虛擬網卡。
因為RDMA Read的交互相對更復雜，所以我們在兩個虛擬機執行的是ibv_read_bw（ibv_send_bw執行會報錯，原因還未搞清楚）：
ib_write_bw -d siw_0 -R -n 5 -s 1500 ib_write_bw -d siw_0 -R -n 5 -s 1500 192.168.217.128其中，-R表示使用CM建鏈（Socket建鏈不通，原因未知）；-n 5表示跑5輪測試，畢竟是個測試性能的工具，循環次數越多，結果越可信。因為我們只關心報文，所以取了perftest迭代次數的最小值5；-s是消息長度，也就是用戶數據的長度，取1500我是為了能夠演示把payload切成多個DDP的數據包，其他值亦可。
所以我們這次跑的測試的內容是：使用CM建鏈，client端從server端使用RDMA Read操作讀回長度為1500的數據，循環5次。
執行完畢后我們來看一下抓包結果，我們只關注其中的DDP/RDMA協議。
Send
取一個Send操作的DDP Segment，首先我們可以看到自上而下是從Ethernet層到DDP/RDMAP層的清晰的層次關系：
這個DDP消息是用來交換雙方的信息的，我們不關注具體內容，只看它的Header。從其中我們可以得到以下信息：
- 這是一個Untagged Buffer Model的報文
- 是整個DDP Message的最后一個Segment
- DDP協議版本是1
- 接收隊列的QN是0
- 消息序列號是8，說明之前0號隊列已經接受了7個消息了
- 消息偏移是0，說明數據會放到Buffer的頭部（也說明這個Message只有1個Segment）
RDMAP和MPA的內容我們會在以后的文章中講解，目前不用關心。
RDMA Read
首先來看Client端發給Server的RDMA Read Request的DDP Message：
還是只看DDP Header部分，發現這也使用了Untagged Buffer，并且只有一個Segment，就不每個字段都解釋了。Read Request本身不攜帶用戶數據，可以看到下面的RDMAP Header中攜帶的是兩端的Buffer的信息。
然后我們來看緊跟其后的RDMA Read Request的DDP Message：
首先比較明顯的是，這個Message包含兩個Segment：
Segment 1
Segment 2
它們使用的是Tagged Buffer Model，使用相同的STag，TO偏移相差0x594（1428）。
我們重點來看一下這個TO是怎么來的。
環境中兩端虛擬機網卡的MTU都是1500，說明Ethernet層之上的內容，需要切割成1500字節為單位的單元。因為要包含各層的Header以及校驗信息，所以最終的Payload肯定不能是1500。
只需要用1500減去各種控制信息，我們就可以知道負載的長度：
1500 - 20 - 32 - 2- 14 - 4 = 1428
這里的TCP Header中包含了可選項Timestamp，所以長度不是20字節，而是32字節。所以第一個DDP Segment只能承載1428字節的Payload，剩余的72個字節要放到第二個Segment中。
另外我們從上面的抓包結果我們也可以看出，正如RFC 5042中指出的那樣，DDP Untagged Buffer Model通常都用于傳遞一些控制信息，數據讀寫更多的還是使用Tagged Buffer Model。
除了上述內容外，RFC 5041還介紹了DDP流的建立和銷毀、錯誤檢測和安全機制等內容。我將在RDMAP的文章中一并講解。
好了，本文就到這里，下一篇打算介紹iWARP和Soft-iWARP或者RDMAP。
參考資料
[1]?RFC 5041
[2]?RFC 5042
[3] Understanding iWARP.?https://www.intel.com/content/dam/support/us/en/documents/network/sb/understanding_iwarp_final.pdf
總結
以上是生活随笔為你收集整理的【RDMA】16. RDMA之DDP(Direct Data Placement)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Excel每隔2行间隔设定颜色，是表格更
- 下一篇： GOTS认证有四个特点，你知道吗