Compartilhar via

Requisitos de tratamento de conclusão do NDKPI

  • Artigo

Os consumidores do NDK e os provedores NDK devem seguir esses requisitos para o tratamento de conclusão do NDKPI.

As funções Rules for NdkGetCqResults, NdkGetCqResultsEx e NdkArmCq

O consumidor sempre serializará suas chamadas para essas funções de provedor no mesmo objeto CQ (fila de conclusão) (NDK_CQ):

Isso significa não apenas que o consumidor nunca chamará a mesma função de provedor várias vezes simultaneamente, mas também que nunca chamará qualquer combinação dessas funções simultaneamente no mesmo CQ de vários threads.

Uma conclusão de NdkOperationTypeReceiveAndInvalidate que ocorre como resultado de uma chamada remota de NdkSendAndInvalidate (NDK_FN_SEND_AND_INVALIDATE) ainda deve ser recuperável usando NdkGetCqResults (não NdkGetCqResultsExn). Isso ainda deve invalidar o token especificado no receptor, mas não notificará o consumidor receptor dessa invalidação (o consumidor deve usar NdkGetCqResultsEx para obter essas informações). Um NdkInvalidate (NDK_FN_INVALIDATE) posterior para o mesmo token falhará, como de costume.

As regras para retornos de chamada de notificação

O provedor deve chamar o retorno de chamada NdkCqNotificationCallback (NDK_FN_CQ_NOTIFICATION_CALLBACK) apenas uma vez e somente depois que o consumidor armar o retorno de chamada NdkCqNotificationCallback chamando NdkArmCq. Ou seja, o provedor deve limpar o braço e chamar o retorno de chamada NdkCqNotificationCallback quando as condições para chamar o retorno de chamada NdkCqNotificationCallback ocorrerem (em outras palavras, quando as conclusões da solicitação são enfileiradas no CQ).

Se já houver conclusões no CQ quando o consumidor chamar NdkArmCq, o provedor se comportará da seguinte maneira:

  • Se pelo menos uma das conclusões tiver sido colocada recentemente no CQ desde que o último retorno de chamada NdkCqNotificationCallback foi chamado, o provedor deverá atender à solicitação arm imediatamente (veja abaixo os requisitos de serialização).
  • No entanto, se todas as conclusões no CQ também estavam presentes quando o último retorno de chamada NdkCqNotificationCallback foi chamado (em outras palavras, o consumidor chamado NdkArmCq sem remover todas as conclusões e nenhuma nova conclusão foi colocada no CQ), então o provedor pode atender à solicitação arm imediatamente.

Quando o provedor precisar chamar o retorno de chamada NdkCqNotificationCallback , se já houver um retorno de chamada NdkCqNotificationCallback em andamento, o provedor deverá adiar a invocação do retorno de chamada NdkCqNotificationCallback até que a chamada existente para o retorno de chamada NdkCqNotificationCallback retorne o controle para o provedor. Em outras palavras, o provedor é responsável por serializar os retornos de chamada NdkCqNotificationCallback .

A tabela a seguir mostra o tipo de braço resultante se NdkArmCq for chamado uma segunda vez antes que uma solicitação NdkArmCq anterior seja atendida:

2º braço ANY ERROS do 2º braço 2º braço SOLICITADO

1º braço ANY

ANY

ANY

ANY

Erros do 1º braço

ANY

ERROS

SOLICITADO

1º braço SOLICITADO

ANY

SOLICITADO

SOLICITADO

NDKPI (Network Direct Kernel Provider Interface)