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

Схема отложенной обработки 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.

Сетевой интерфейс поставщика ядра (NDKPI)