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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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