Совместное использование памяти RDMA

У меня есть несколько многоядерных компьютеров, соединенных сетью Infiniband. Я хотел бы иметь некоторые вычисления с малой задержкой в ​​​​пуле общей памяти с удаленными атомарными операциями. Я знаю, что RDMA — это путь. На каждом узле я бы зарегистрировал область памяти (и домен защиты) для обмена данными.

Онлайн-примеры RDMA часто фокусируются на одном соединении между однопоточным сервером и однопоточным клиентом. Теперь я хотел бы иметь многопоточный процесс на каждом узле Infiniband. Меня очень озадачило следующее...

  1. Сколько пар очередей я должен подготовить на каждом узле, всего для кластера из n узлов и m потоков? Чтобы быть более конкретным, могут ли несколько потоков на одном узле совместно использовать одну и ту же пару очередей?

  2. Сколько очередей завершения я должен подготовить на каждом узле? У меня будет несколько потоков, выполняющих удаленные операции чтения/записи/cas на каждом узле. Если бы они использовали общую очередь завершения, события завершения были бы перепутаны. Если бы у потоков были свои отдельные очереди завершения, их было бы действительно много.

  3. Вы предлагаете мне иметь какие-либо существующие библиотеки вместо того, чтобы писать это программное обеспечение? (хм, или я должен написать один и открыть его исходный код? :-)

Спасибо за ваше любезное предложение (я).


infiniband rdma
person Kinson Chan    schedule 27.02.2012    source источник

Ответы (1)


arrow_upward
9
arrow_downward

По крайней мере, в Linux библиотека глаголов InfiniBand полностью потокобезопасна. Таким образом, вы можете использовать столько пар очередей (QP) в своем многопоточном приложении, сколько хотите — несколько потоков могут безопасно отправлять рабочие запросы в один QP, хотя, конечно, вам придется убедиться, что любое отслеживание ожидающих запросов запросы и т. д., которые вы выполняете в своем собственном приложении, являются потокобезопасными.

Это правда, что каждая очередь отправки и каждая очередь получения (помните, что QP на самом деле является парой очередей :) присоединены к одной очереди завершения (CQ). Поэтому, если вы хотите, чтобы каждый поток имел свой собственный CQ, тогда каждому потоку потребуется свой собственный QP для отправки работы.

В целом QP и CQ на самом деле не являются ограниченным ресурсом — вы можете легко иметь сотни или тысячи на одном узле без проблем. Таким образом, вы можете разрабатывать свое приложение, не слишком беспокоясь об абсолютном количестве используемых вами очередей. Это не означает, что вам не нужно беспокоиться о масштабируемости — например, если у вас много очередей приема и много буферов на каждую очередь, вы можете задействовать слишком много памяти в буферизации приема, так что в итоге вы необходимость использования общих очередей приема (SRQ).

Существует ряд библиотек промежуточного программного обеспечения, использующих IB; вероятно, MPI (например, http://open-mpi.org/) является наиболее известным и вероятно, стоит оценить это, прежде чем вы зайдете слишком далеко в переосмыслении вещей. Разработчики MPI также опубликовали множество исследований по эффективному использованию IB/RDMA, которые, вероятно, стоит поискать, если вы решите построить свою собственную систему.

person Roland    schedule 27.02.2012
comment
А исходники пар очередей (QP), очереди завершения (CQ) и разделяемых очередей приема (SRQ) надо писать самостоятельно, или можно получить их реализацию готовой (как наилучшая практика) и где их можно взять? - person Alex; 02.09.2013