RDMA - аппаратное решение для прямого доступа к памяти другого компьютера при помощи высокоскоростной сети. Методом пересылки данных с высокой пропускной способностью и низкой latency позволяет получить доступ к данным, хранящимся в удалённой системе, без привлечения средств операционных систем обоих компьютеров. Исключаются лишние копирования между приложением и буферами операционной системы, снижается объём работы центрального процессора, нагрузка на кэш-память, уменьшается количество переключений контекста, а сами передачи могут производиться одновременно с другой полезной работой. Полезен в больших параллельных вычислительных системах — кластерах.

RoCE это развитие RDMA от InfiniBand Trade Association. Предшественником RoCE был iWARP, по сравнению с которым RoCE более энергоэффективен и производителен. У RoCE есть две версии, RoCE v1 и v2. Если вкратце, то RoCEv1 оперирует в L2, а RoCEv2 - маршрутизируемый трафик UDP в L4. Далее по тексту пойдет речь как раз о v2.

ECN - Explicit Congestion Notification, грубо - это уведомления о перегруженности в сети, оперирующие на L4 уровне. Нужно для того, чтобы пакеты не отбрасывались, а складывались в очередь. RoCEv2 ведь, как никак, lossless, а значит передача без потерь, и помним, что RoCEv2 UDP, соответственно, если мы отбросим пакеты, то они более переданы не будут.

Priority Flow Control (PFC) IEEE 802.1Qbb - это паузы для входящего трафика, чтобы уведомить одноранговый узел о необходимости приостановить передачу, когда канал перегружен. Смысл этой технологии в том, чтобы в моменты затора в сетях центров обработки данных (dcb) пакеты RoCE имели приоритет над трафиком TCP, а следовательно, при больших загрузках каналов не было тротлинга по сети хранения SAN.
Чтобы понять, что перед нами кадр PFC, свитч или конечное устройство может анализировать 3 бита заголовка vlan на уровне L2 - PCP (Priority Code Point), или, если нет vlan, то применяется DSCP (Differentiated Services Code Point), а это уже L3 уровень и производится анализ 6 бит в заголовке IP. Если всё верно настроено, то кадры попадают в нужный буфер и не теряются. В остальных случаях будет происходить drop пакетов. Кстати DSCP как реализация появилась чуть позже, чем PCP и, как следствие, поначалу RoCEv2 работал только в vlan.

С вашего позволения, я не буду упарываться рассказывать о случаях, когда присутствуют несколько свитчей в mlag и в свитчах пакеты PFC без vlan, а mlag соединение в vlan, и требуется пересылка пакетов RoCE через mlag. Т.е. внутри свитча действует DSCP, а между свитчами в соединении mlag уже PCP. Это более сложный вариант, и я его опишу, если вы это потребуете, отдельным постом.

При включенном PFC сети гарантируют доставку пакетов в рамках выбранного приоритета. Однако, со всеми преимуществами PFC привносит и очередной сценарий отказа, при котором очередь конечного порта (например, порта хоста, подключенного к сети) может не иметь возможности получать какой-либо трафик из сети и продолжать отправлять кадры паузы в сторону коммутатора. Если очередь конечного порта зависает на долгое время, буферы заполняются не только на одном коммутаторе, но и на всех коммутаторах с проблемными очередями портов на пути пересылки трафика. Это приводит к появлению бесконечных кадров паузы PFC, так же называемых штормом PFC.

Для предотвращения таких штормов реализован PFC Watchdog. Когда коммутаторы обнаруживают эту ситуацию в любой очереди TC, все пакеты в очереди сбрасываются, а новые пакеты, предназначенные для той же очереди, также отбрасываются до тех пор, пока не закончится шторм PFC.

Включать ли PFC Watchdog каждый решает сам. Я не включал, поскольку у меня исключена ситуация пересылки PFC из свитча в свитч.

Data center bridging - это расширение протокола Ethernet. Для выбранного типа класса трафика устраняет потери, связанные с переполнением очереди. По сути, DCB позволяет в некоторой степени рассматривать разные приоритеты, как если бы это были разные каналы.  DCB различает потоки трафика, помечая трафик определенным значением от 0 до 7.
Обычно потерянные пакеты данных не являются большой проблемой, поскольку они будут повторно переданы по TCP/IP, но с трафиком хранилища потерянные пакеты данных снижают производительность, поскольку они приводят к задержкам ввода-вывода, что неприемлемо. DCB использует значения CoS, чтобы указать, какое значение должно быть передано без потерь через сеть. Обычно сетевые коммутаторы поддерживают до трех значений CoS.
DCBX является расширением протокола DCB, где «X» означает eXchange. Смысл DCBX в автоматической передаче настроенных параметров очередей коммутатора на сетевые карты серверов.

Когда пакет поступает на коммутатор, он классифицируется в соответствии с входным портом, выходным портом и полями заголовка уровня L2 и L3. Следующие термины используются для классификации пакетов внутри коммутатора:

Порты:

• Ingress port (iPort) – порт, на который получен пакет.

• Egress port (ePort) – порт, который передает пакет.

Пулы:

• Ingress pool (iPool) – пул памяти для входящего трафика.

• Egress pool (ePool) — пул памяти для исходящего трафика.

Приоритеты:

• Switch priority (SP) внутренний идентификатор приоритета пакета, который используется в качестве ключа для некоторых внутренних функций и решений коммутатора, включая буферизацию. SP пакета назначается в соответствии с конфигурацией уровня доверия порта и идентификаторами QoS пакета в заголовке (PCP, DEI, DSCP).

• Priority group (PG) PG объединяет группу SP. Он используется для группировки пакетов с несколькими приоритетами коммутатора в одном буфере. Диапазон PG — от 0 до 7. PG 9 зарезервирован для управляющего трафика.

• Traffic class (TC) TC объединяет группу SP. Он используется для группировки пакетов с несколькими приоритетами коммутатора в одну выходную очередь и буферное пространство. Диапазон TC составляет от 0 до 15, при этом TC 8–15 зарезервирован для многоадресного трафика, а TC 16 зарезервирован для управляющего трафика.

Механизм настройки буфера позволяет выделить буферное пространство для определенных типов трафика путем настройки буферов следующих типов:

• iPort.PG – трафик, который поступает на определенный порт и сопоставляется с определенной PG.

• iPort (iPort.pool) – трафик, который поступает на определенный порт и учитывается на конкретном iPool. Суммирует все iPort.PG, сопоставленные с указанным iPool.

• ePort.TC – трафик, который передается на определенный порт и отображается на определенный TC.

• ePort (ePort.pool) – трафик, который передается на определенный порт и учитывается на конкретном ePool. Он должен суммировать все ePort.TC, сопоставленные с указанным ePool.

Поскольку многоадресные пакеты дублируются между выходными портами, чтобы обеспечить согласованный подсчет пакетов на входящей и исходящей сторонах, используются следующие типы буферов:

• MC.SP – многоадресный трафик, который классифицируется по определенному приоритету коммутатора. Подсчет происходит на выходной стороне до дублирования пакетов.

• ePort.mc – многоадресный трафик, который будет передаваться на определенный порт.

Буферы могут делиться на основе резервирования и распределения памяти:

• Reserved allocation (size) - буфер с гарантированной квотой, которая не используется совместно пулами

• Shared allocation (shared) - максимально возможная квота буферизации, которую можно использовать совместно с другими буферами и распределять динамически. Использование буфера не может превышать данную квоту. Совместное распределение можно установить с использованием статического или динамического порога распределения.

Буфер iPort.PG можно настроить для работы в одном из двух режимов:

• Lossy – для трафика с потерями.

• Lossless – для трафика без потерь. В этом режиме пользователь должен определить пороговые значения управления потоком (Xoff, Xon). Достижение порога Xoff при занятости буфера PG будет генерировать кадры «паузы» для отправителя. Достижение порога Xon прекращает передачу кадров «на паузу». Зарезервированное выделение памяти для этого буфера должно быть не менее значения Xoff, чтобы обеспечить достаточную буферизацию ingress пакетов.

После первоначального допуска в буфер, в котором определены его egress порт, TC и ingress PG, пакет оценивается на предмет его пригодности для хранения в буферном пространстве до тех пор, пока он не будет перенаправлен.

Flags:
  Y: Lossy
  L: Lossless
  S: Static
  D: Dynamic

  Shared size is in percent/Bytes for static pool and in alphas for dynamic pool

Interface Eth1/1:
  ------------------------------------------------------------------------------------------
  Buffer              Resv      Xoff      Xon       Shared        Pool          Description
                      [Byte]    [Byte]    [Byte]    [%/a/Byte]                  
  ------------------------------------------------------------------------------------------
  iPort.iPool0(Y)     10.0K     -         -         alpha 8       iPool0(D)     
  iPort.iPool1(Y)     0         -         -         alpha 1       iPool1(D)     
  iPort.iPool2(Y)     0         -         -         alpha 0       iPool2(D)     
  iPort.iPool3(Y)     0         -         -         alpha 0       iPool3(D)     
  iPort.iPool4(Y)     0         -         -         alpha 0       iPool4(D)     
  iPort.iPool5(Y)     0         -         -         alpha 0       iPool5(D)     
  iPort.iPool6(Y)     0         -         -         alpha 0       iPool6(D)     
  iPort.iPool7(Y)     0         -         -         alpha 0       iPool7(D)     
  iPort.iPoolCtrl(Y)  0         -         -         alpha 8       iPoolCtrl(D)  
  iPort.pg0(Y)        0         -         -         alpha 8       iPool0(D)     
  iPort.pg1(L)        63.4K     19.0K     19.0K     alpha 1       iPool1(D)     
  iPort.pg2(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg3(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg4(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg5(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg6(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg7(Y)        0         -         -         alpha 0       iPool0(D)     
  iPort.pg9(Y)        10.0K     -         -         alpha 8       iPoolCtrl(D)  
  ePort.ePool0        5.0K      -         -         alpha 8       ePool0(D)     
  ePort.ePool1        0         -         -         alpha inf     ePool1(D)     
  ePort.ePool2        0         -         -         alpha 0       ePool2(D)     
  ePort.ePool3        0         -         -         alpha 0       ePool3(D)     
  ePort.ePool4        0         -         -         alpha 0       ePool4(D)     
  ePort.ePool5        0         -         -         alpha 0       ePool5(D)     
  ePort.ePool6        0         -         -         alpha 0       ePool6(D)     
  ePort.ePool7        0         -         -         alpha 0       ePool7(D)     
  ePort.mc            0         -         -         inf           ePool15(S)    
  ePort.ePoolCtrl     0         -         -         alpha 8       ePoolCtrl(D)  
  ePort.tc0           1.0K      -         -         alpha 8       ePool0(D)     
  ePort.tc1           0         -         -         alpha 0       ePool0(D)     
  ePort.tc2           0         -         -         alpha 0       ePool0(D)     
  ePort.tc3           0         -         -         alpha inf     ePool1(D)     
  ePort.tc4           0         -         -         alpha 0       ePool0(D)     
  ePort.tc5           0         -         -         alpha 0       ePool0(D)     
  ePort.tc6           1.0K      -         -         alpha 8       ePool0(D)     
  ePort.tc7           0         -         -         alpha 0       ePool0(D)     
  ePort.tc16          1.0K      -         -         alpha 8       ePoolCtrl(D)  

  switch-priority to Buffers mapping:
    ------------------------------
    Switch-priority    Buffer    
    ------------------------------
    0                  iPort.pg0 
    1                  iPort.pg0 
    2                  iPort.pg0 
    3                  iPort.pg1 
    4                  iPort.pg0 
    5                  iPort.pg0 
    6                  iPort.pg0 
    7                  iPort.pg0 

Здесь видим, что switch-priority 3 смотрит в буфер iPort.pg1, который в свою очередь обозначен (L) lossless и находится в динамическом пуле iPool1. i перед Pool это ingress, т.е. входящий трафик. Аналогично для исходящего трафика egress ePort.tc3 - исходящий трафик с контекстом 3.

/var/log/vmkernel.log на ESXi и убедиться, что у вас-то всё в порядке и всё работает!

esxcli network nic list
Name    PCI Device    Driver      Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description
------  ------------  ----------  ------------  -----------  -----  ------  -----------------  ----  -----------
...
vmnic4  0000:5d:00.0  nmlx5_core  Up            Up           25000  Full    e0:07:1b:xx:xx:xx  9000  Mellanox Technologies MT27710 Family [ConnectX-4 Lx]
vmnic5  0000:5d:00.1  nmlx5_core  Up            Up           25000  Full    e0:07:1b:xx:xx:xx  9000  Mellanox Technologies MT27710 Family [ConnectX-4 Lx]

esxcli rdma device list
Name     Driver      State    MTU  Speed    Paired Uplink  Description
-------  ----------  ------  ----  -------  -------------  -----------
vmrdma0  nmlx5_rdma  Active  4096  25 Gbps  vmnic4         MT27710 Family  [ConnectX-4 Lx]
vmrdma1  nmlx5_rdma  Active  4096  25 Gbps  vmnic5         MT27710 Family  [ConnectX-4 Lx]

esxcli network nic dcb status get -n vmnic4
   Nic Name: vmnic4
   Mode: 3 - IEEE Mode
   Enabled: true
   Capabilities: 
         Priority Group: true
         Priority Flow Control: true
         PG Traffic Classes: 8
         PFC Traffic Classes: 8
   PFC Enabled: true
   PFC Configuration: 0 0 0 1 0 0 0 0
   IEEE ETS Configuration: 
         Willing Bit In ETS Config TLV: 1
         Supported Capacity: 8
         Credit Based Shaper ETS Algorithm Supported: 0x0
         TX Bandwidth Per TC: 50 0 0 50 0 0 0 0
         RX Bandwidth Per TC: 50 0 0 50 0 0 0 0
         TSA Assignment Table Per TC: 2 2 2 2 2 2 2 2
         Priority Assignment Per TC: 0 0 0 3 0 0 6 0
         Recommended TC Bandwidth Per TC: 50 0 0 50 0 0 0 0
         Recommended TSA Assignment Per TC: 2 2 2 2 2 2 2 2
         Recommended Priority Assignment Per TC: 0 0 0 3 0 0 6 0
   IEEE PFC Configuration: 
         Number Of Traffic Classes: 8
         PFC Configuration: 0 0 0 1 0 0 0 0
         Macsec Bypass Capability Is Enabled: 0
         Round Trip Propagation Delay Of Link: 0
         Sent PFC Frames: 0 0 0 0 0 0 0 0
         Received PFC Frames: 0 0 0 0 0 0 0 0
   DCB Apps: 

esxcli system module parameters list -m nmlx5_core | grep 'trust_state\|pfcrx\|pfctx'

Проверяем, что параметры применились

2023-11-03T04:01:29.072Z Wa(180) vmkwarning: cpu57:2098375)WARNING: rdmaDriver: RDMAFindTeamDeviceByPortID:3147: Unspported team policy = 8 status = Success                                                                   
2023-11-03T04:01:29.072Z Wa(180) vmkwarning: cpu57:2098375)WARNING: rdmaDriver: RDMACM_BindLegacy:4306: The provided interface (192.168.205.11) does not have a registered rdma device.                                       
2023-11-03T04:01:29.072Z In(182) vmkernel: cpu57:2098375)RDT: RDTCreateRDMAServer:2754: vmk_RDMACMBind() failed for server Bad parameter                                                                                       
2023-11-03T04:01:29.072Z In(182) vmkernel: cpu57:2098375)RDT: RDTCreateRDMAServer:2787: RDTCreateRDMAServer() exiting with failure                                                                                             
2023-11-03T04:01:29.072Z In(182) vmkernel: cpu57:2098375)RDT: RDTEnableRdmaInt:642: Failed to create listener for address 192.168.205.11, protocol 2, status Bad parameter                                                     
2023-11-03T04:01:34.074Z In(182) vmkernel: cpu62:2098375)RDT: RDTDisableRdmaInt:722: SupportedTransportProtocolsMask removes RDMA

то проверьте, как настроены аплинки в вашем виртуальном свитче. LAG не работает, nic teaming работает исключительно в режиме "use explicit failover order".

Интересный факт - в статье NVIDIA говорится, что аплинки должны быть в режиме  "route based on physical nic load". Ну так вот оно так не работает, только режим "explicit failover order" и никак иначе.

show interface ethernet 1/1 counters roce

Eth1/1:
  Rx:
    1237468664            RoCE PG packets
    910484091264          RoCE PG bytes
    0                     RoCE no buffer discard
    78086993              CNP PG packets
    165974383879          CNP PG bytes
    0                     CNP no buffer discard
    6                     RoCE PFC pause packets
    391                   RoCE PFC pause duration
    0                     RoCE buffer usage (bytes)
    828288                RoCE buffer max usage (bytes)
    0                     CNP buffer usage (bytes)
    2492448               CNP buffer max usage (bytes)
    0                     RoCE PG usage (bytes)
    828288                RoCE PG max usage (bytes)
    0                     CNP PG usage (bytes)
    2492448               CNP PG max usage (bytes)

  Tx:
    1228356               ECN marked packets
    1488922017            RoCE TC packets
    2063482007374         RoCE TC bytes
    0                     RoCE unicast no buffer discard
    368148                CNP TC packets
    28715544              CNP TC bytes
    0                     CNP unicast no buffer discard
    0                     RoCE PFC pause packets
    0                     RoCE PFC pause duration
    0                     RoCE buffer usage (bytes)
    1120224               RoCE buffer max usage (bytes)
    0                     CNP buffer usage (bytes)
    2746848               CNP buffer max usage (bytes)
    0                     RoCE TC usage (bytes)
    1120224               RoCE TC max usage (bytes)
    0                     CNP TC usage (bytes)
    96                    CNP TC max usage (bytes)

vsish -e cat /net/pNics/vmnic4/stats | grep -e "Pause\|PerPrio"
rxPauseCtrlPhy: 0
txPauseCtrlPhy: 6
txPauseStormWarningEvents: 0
txPauseStormErrorEvents: 0

Если после серьезной нагрузки счетчики по нулям, возможно, что у вас что-то не работает, либо же вы не уперлись в производительность сетевых интерфейсов.