2012-02-27 3 views
8

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

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

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

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

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

Благодарим за ваши предложения (предложения).

ответ

8

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

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

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

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

+0

И исходный код пар очередей (QP), очередь завершения (CQ) и общие очереди приема (SRQ) должны писать самостоятельно, или я могу получить их реализацию (как наилучшую практику) и где они могут брать? – Alex

Смежные вопросы