Partager via

Schéma de traitement différé NDKPI

  • Article

Il existe de nombreux cas où un consommateur NDK publiera une chaîne de demandes d’initiateur dans la paire de files d’attente (QP). Par exemple, un consommateur peut publier un certain nombre de demandes d’inscription rapides suivies d’une demande d’envoi. Les performances de ces modèles de requête peuvent être améliorées si la chaîne de requêtes est mise en file d’attente vers le QP, puis indiquée au matériel pour traitement en tant que lot, au lieu d’indiquer chaque requête de la chaîne au matériel, une par une.

La valeur de l’indicateur NDK_OP_FLAG_DEFER peut être utilisée à cet effet avec les types de requête suivants :

La présence de l’indicateur indique au fournisseur NDK qu’il peut différer l’indication de la demande au matériel pour traitement, mais le fournisseur peut traiter la nouvelle demande à tout moment.

La présence de l’indicateur NDK_OP_FLAG_DEFER sur une demande d’initiateur ne modifie pas les responsabilités existantes du fournisseur NDK en ce qui concerne la génération d’achèvements. Un appel à la demande de l’initiateur qui retourne un échec status ne doit pas entraîner la mise en file d’attente d’une complétion vers le CQ pour la demande ayant échoué. À l’inverse, un appel qui retourne une status réussie doit finalement entraîner la mise en file d’attente d’une exécution au CQ tant que le consommateur respecte les exigences supplémentaires répertoriées ci-dessous.

En plus de toutes les exigences NDK existantes, deux exigences supplémentaires (l’une pour le fournisseur et l’autre pour le consommateur) doivent être respectées afin d’éviter une situation dans laquelle les demandes sont correctement publiées sur le QP avec l’indicateur NDK_OP_FLAG_DEFER , mais ne sont jamais indiquées au matériel pour traitement :

  • Lors du retour d’un échec status d’un appel à une demande d’initiateur, le fournisseur doit garantir que toutes les demandes précédemment envoyées avec l’indicateur NDK_OP_FLAG_DEFER sont indiquées au matériel pour traitement.
  • Le consommateur garantit qu’en l’absence d’un échec inline, toutes les chaînes de demandes de l’initiateur seront arrêtées par une requête de l’initiateur qui ne définit pas l’indicateur NDK_OP_FLAG_DEFER .

Par exemple, prenons un cas où un consommateur a une chaîne de deux demandes d’inscription rapides et un envoi qu’il doit publier sur le QP :

  1. Le consommateur publie le premier registre rapide avec l’indicateur NDK_OP_FLAG_DEFER et NdkFastRegister retourne STATUS_SUCCESS.
  2. Là encore, le deuxième registre rapide est publié avec l’indicateur NDK_OP_FLAG_DEFER défini, mais maintenant NdkFastRegister retourne un échec status. Dans ce cas, le consommateur ne publiera pas la demande d’envoi.
  3. Lors du retour de l’échec inline pour le deuxième appel à NdkFastRegister, le fournisseur NDK s’assure que toutes les demandes précédemment non inscrites (le premier registre rapide dans ce cas) sont indiquées au matériel pour traitement.
  4. Étant donné que le premier appel à NdkFastRegister a réussi, une saisie semi-automatique doit être générée dans le CQ.
  5. Étant donné que le deuxième appel à NdkFastRegister a échoué en ligne, une saisie semi-automatique ne doit pas être générée dans le CQ.

Network Direct Kernel Provider Interface (NDKPI)