Разделение памяти RDMA - PullRequest
       73

Разделение памяти RDMA

8 голосов
/ 27 февраля 2012

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

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

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

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

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

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

1 Ответ

8 голосов
/ 27 февраля 2012

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

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

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

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

...