У нас накопился массив материалов, связанных с изучением архитектуры Remote Direct Memory Access. Во время его формирования ряд моментов стали более понятны, но механизмы некоторых реализаций по-прежнему остались только в виде предположений. К сожалению, существующая проблематика удаленного доступа непосредственно к памяти сводится к упрощенной модели отказа от лишних пересылок. Очевидно, что в случае с RDMA мы имеем дело с сущностью, порождающей новое качество межплатформенного взаимодействия, базис которого заложен такими краеугольными понятиями как IfiniBand и NUMA. (Здесь и далее под RDMA мы подразумеваем RoCE – одну из актуальных Zero-Copy реализаций прямого доступа к памяти, сведенных к привычному Ethernet-транспорту).

Для понимания места RDMA в существующей проблематике высокопроизводительных вычислений (и связанных с этим перспективах развития серверостроения) хотелось бы найти ответ на такие вопросы, которые оказались «за кадром» текущего информационного сопровождения. (Речь, безусловно, идет о текстах, сгенерированных ведущими производителями RNIC-контроллеров, а именно: Broadcom, Intel, Mellanox).

Классификация операций и производительность

На сегодня до конца не проясненными остаются два момента. Самый важный из них – модель доступа к памяти. Как известно, обмен по сети может вестись с помощью тегированных запросов (операции Read и Write) и нетегированных (операция Send). Насколько хороши каждая из моделей в плане производительности? И может ли пользователь если не управлять выбором, то хотя бы анализировать статистику RDMA-транзакций в указанном разрезе?



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

Это не праздное любопытство: результаты, полученные в серии экспериментов свидетельствуют о том, что преимущества и возможности «черного RDMA-ящика», как и ожидалось, не бесконечны. Массированные пересылки данных становятся непосильным бременем, что для продвинутой технологии, что для вечно живой классики. Смотрим учебно-образовательный ролик Mellanox (обратите внимание на фрагмент, который начинается с 29:04):



Здесь на повестку дня выходит глубокое понимание и тонкий тюнинг – залог эффективности. В такой ситуации уместно поинтересоваться, нет ли конфликта критериев производительности с требованиями совместимости? Ведь если это так, то для эффективного использования технологии RDMA потребуется более радикальный редизайн программного обеспечения – от низкоуровневых драйверов до пользовательских приложений.

Bus Master vs DMA Engine

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

• Децентрализованная модель подразумевает, что RNIC-контроллер в режиме Bus Master способен самостоятельно взаимодействовать с оперативной памятью, выполняя операции чтения и записи; здесь можно говорить о том, что DMA-контроллер является частью RNIC.
• Централизованная модель использует узел DMA Engine, входящий в состав процессоров Intel Xeon; это своеобразный процессор ввода-вывода, обеспечивающий аппаратную поддержку быстрого перемещения огромных объемов данных, с элементами интеллектуальной обработки, востребованной для реализации ряда устройств, например, дисковых RAID-массивов и сетевых NIC-контроллеров; этот узел пришел на смену «древнему» DMA-контроллеру Intel 8237, архитектура которого была разработана еще до появления шины ISA.

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

Эффективная инкапсуляция низкоуровневых аспектов архитекторами RDMA-протокола не позволила нам прийти к однозначному выводу, какой из методов (децентрализованный или централизованный) предпочли разработчики. Хотя уже сегодня есть весомые аргументы в пользу применения Bus Master в силу того, что сценарий для операций доступа к памяти управляется информацией, приходящей по сети. Тем не менее, предстоит еще найти ответ на этот вопрос: разумно предположить, что поддерживаются оба варианта и все зависит от конфигурации платформы…