Schema di elaborazione posticipato di ND KPI

  • Articolo

Esistono molti casi in cui un consumer NDK posticherà una catena di richieste di iniziatori alla coppia di code (QP). Ad esempio, un consumer potrebbe pubblicare una serie di richieste di registrazione rapida seguite da una richiesta di invio. Le prestazioni per tali modelli di richiesta possono essere migliorate se la catena di richieste viene accodata al QP e quindi indicato all'hardware per l'elaborazione come batch, anziché indicare ogni richiesta nella catena all'hardware, una per una.

Il valore del flag NDK_OP_FLAG_DEFER può essere usato per questo scopo con i tipi di richiesta seguenti:

La presenza del flag è un suggerimento al provider NDK che può rinviare la richiesta all'hardware per l'elaborazione, ma il provider può elaborare la nuova richiesta in qualsiasi momento.

La presenza del flag di NDK_OP_FLAG_DEFER in una richiesta di iniziatore non modifica le responsabilità esistenti del provider NDK rispetto alla generazione di completamento. Una chiamata alla richiesta dell'iniziatore che restituisce uno stato di errore non deve comportare la coda di un completamento alla CQ per la richiesta non riuscita. Al contrario, una chiamata che restituisce uno stato di esito positivo deve generare un completamento in coda al CQ, purché il consumer segue i requisiti aggiuntivi elencati di seguito.

Oltre a tutti i requisiti NDK esistenti, è necessario osservare due requisiti aggiuntivi (uno per il provider e uno per il consumer) per evitare una situazione in cui le richieste vengono inviate correttamente al QP con il flag di NDK_OP_FLAG_DEFER , ma non vengono mai indicate per l'hardware per l'elaborazione:

  • Quando si restituisce uno stato di errore da una chiamata a una richiesta di iniziatore, il provider deve garantire che tutte le richieste inviate in precedenza con il flag di NDK_OP_FLAG_DEFER siano indicate nell'hardware per l'elaborazione.
  • Il consumer garantisce che, in assenza di un errore inline, tutte le catene di richieste dell'iniziatore verranno terminate da una richiesta di iniziatore che non imposta il flag di NDK_OP_FLAG_DEFER .

Si consideri ad esempio un caso in cui un consumer ha una catena di due richieste di registrazione rapida e un invio che deve inviare al QP:

  1. Il consumer pubblica il primo registro rapido con il flag di NDK_OP_FLAG_DEFER e NdkFastRegister restituisce STATUS_SUCCESS.
  2. Di nuovo, il secondo registro rapido viene pubblicato con il flag NDK_OP_FLAG_DEFER impostato, ma ora NdkFastRegister restituisce uno stato di errore. In questo caso, il consumer non posterà la richiesta di invio.
  3. Quando si restituisce l'errore inline per la seconda chiamata a NdkFastRegister, il provider NDK assicura che tutte le richieste non indicata in precedenza (il primo registro rapido in questo caso) siano indicate nell'hardware per l'elaborazione.
  4. Poiché la prima chiamata a NdkFastRegister ha avuto esito positivo, è necessario generare un completamento al CQ.
  5. Poiché la seconda chiamata a NdkFastRegister non è riuscita inline, un completamento non deve essere generato nel CQ.

Interfaccia del provider del kernel diretto di rete (NDKPI)