Поделиться через

Схема отложенной обработки NDKPI

  • Статья

Существует множество случаев, когда потребитель NDK будет размещать цепочку запросов-инициаторов в пару очередей (QP). Например, потребитель может публиковать ряд быстрых запросов регистрации, за которым следует запрос на отправку. Производительность для таких шаблонов запросов может быть улучшена, если цепочка запросов ставится в очередь к QP и затем передаётся на оборудование для обработки в виде пакета, вместо передачи на оборудование каждого запроса в цепочке по отдельности.

Значение флага NDK_OP_FLAG_DEFER можно использовать для этой цели со следующими типами запросов:

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

Наличие флага NDK_OP_FLAG_DEFER в запросе инициатора не изменяет существующие обязанности поставщика NDK в отношении формирования завершений. Вызов запроса инициатора, который возвращает состояние сбоя, не должен приводить к тому, чтобы завершение неудачного запроса помещалось в очередь CQ. И наоборот, вызов, возвращающий состояние успешного выполнения, должен в конечном итоге привести к завершению очереди в CQ, если потребитель следует дополнительным требованиям, перечисленным ниже.

Помимо всех существующих требований NDK, необходимо соблюдать два дополнительных требования (один для поставщика и один для потребителя), чтобы предотвратить ситуацию, в которой запросы успешно размещены в QP с флагом NDK_OP_FLAG_DEFER, но никогда не указываются на оборудование для обработки:

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

Например, рассмотрим случай, когда потребитель имеет цепочку двух быстрых запросов на регистрацию и отправку, которую необходимо опубликовать в QP:

  1. Клиент отправляет первый быстрый регистр с флагом NDK_OP_FLAG_DEFER, и NdkFastRegister возвращает STATUS_SUCCESS.
  2. Снова второй быстрый регистр публикуется с установленным флагом NDK_OP_FLAG_DEFER, но теперь NdkFastRegister возвращает статус ошибки. В этом случае потребитель не будет публиковать запрос на отправку.
  3. При возврате встроенной ошибки для второго вызова NdkFastRegisterпоставщик NDK гарантирует, что все ранее неуказанные запросы (первый быстрый регистр в этом случае) передаются оборудованию для обработки.
  4. Поскольку первый вызов NdkFastRegister успешно выполнен, необходимо создать завершение в CQ.
  5. Так как второй вызов NdkFastRegister не удался, завершение не должно создаваться в CQ.

Интерфейс поставщика Network Direct Kernel (NDKPI)