HPC的低延遲需求來自于很多應用都會通過網格刨分來進行并行運算，然后網格間有復雜而頻繁的通信數據交互，Brain將其稱為“Ghost Cell Exchange”。

因此很多HPC系統將單個報文的延遲(Single packet latency)放在第一位，這也是Infiniband/RoCEv1/RoCEv2非常在意報文大小和HPE Cray構建HPC Ethernet的原因。

在AWS EFA的實踐來看，單個報文的延遲并不是問題，而更重要的是網絡中的擁塞沖突帶來的長尾延遲。通過SRD來解決了幾個問題：

多路徑降低擁塞沖突概率

多路徑解決鏈路失效等問題

MPI的很多操作不需要Reliable Connection的通信語義嚴格保序

解決QP數量多的爆炸問題

關于不兼容RC語義的原因：從Brain的履歷也能大概看出來，由于Brain大量的OpenMPI的開發經歷，所以在構建SRD時選擇了不和標準的RC語義兼容，這也給后續的生態帶來了一些問題。

1. 不使用Infiniband的原因

訪談中Brain介紹了一些原因: "云數據中心很多時候是要滿足資源調度和共享等一系列彈性部署的需求，專用的Infiniband網絡構建的集群如同在汪洋大海中的孤島" 并且國外HPC需求較國內高的原因在訪談中也介紹了：國外并沒有太多的線下機房，通常一些HPC任務需要在一些超算集群排隊數周，如果有一個性能差不多的云上環境，對客戶而言很有吸引力。

2. 應用性能

從應用性能來看，Brain的觀點是單個報文的延遲(Single packet latency)并沒有那么的重要，更重要的是實現長尾延遲的避免,例如Star-CCM+的測試報告《EFA-enabled C5n instances to scale Simcenter STAR-CCM+》[2]，在3000核時加速比都還非常好。

ANSYS Fluent性能也非常好。

訪談中Brain還提到高性能存儲是影響HPC應用的另一個關鍵因素，因此構建了FSx for Lustre的支持。

3. 一些缺點和爭議

AWS通過Reliable Datagram實現了多路徑的支持能力，但是似乎國內很多人把這個事情搞混了，雖然傳輸語義上實現了可交換，但是基于Reliable Connection語義Verbs兼容的情況下依舊可以實現多路徑的處理，而且這個技術在2002年IETF提出iWARP時構建的Direct Data Placement(DDP)就已經討論的很清楚了。

另外在HPC這個領域，特別是在國內部門間的通信壁壘非常高，很多從業者材料/物理/機械這些專業畢業的，對于HPC軟件和相應的求解器只會使用，而IT等部門通常也只是使用商用軟件測試招標，相應的算法和通信等優化的團隊較少，并且企業通常因為軟件授權價格等問題停留在較老的軟件版本上。針對這些商用軟件生態兼容使得RD這樣的語義帶來了很多負擔。

審核編輯：劉清