Portare NVMe/TCP al passo con i tempi

May 22, 2023

Scarica la presentazione:Portare NVMe/TCP al passo con i tempi

Sono Sagi Grimberg. Sono CTO e co-fondatore di Lightbits Labs e sono stato coautore delle specifiche standard NVMe su TCP.

Quindi, inizieremo con una breve introduzione. Cos'è NVMe su TCP? NVMe su TCP è l'associazione di trasporto standard che esegue NVMe su reti TCP/IP standard. Segue la specifica NVMe standard che definisce l'interfaccia di accodamento e l'interfaccia multi-coda che viene eseguita proprio sopra i socket TCP/IP. Ha il set di comandi NVMe standard, sembra essere incapsulato in quelle che chiamiamo PDU NVMe/TCP che mappano i flussi TCP. Quindi, nel diagramma qui, abbiamo fondamentalmente l'architettura NVMe, architetture principali che definiscono l'amministrazione, l'I/O e altri set di comandi.

01:14 GS: Di seguito abbiamo NVMe over Fabrics che definisce capsule, proprietà, scoperta. E NVMe su TCP definisce fondamentalmente funzionalità e messaggistica extra, nonché la mappatura del trasporto alla struttura sottostante stessa, che nel nostro caso è TCP/IP.

Quindi, come viene elaborata una coda da NVMe su TCP o come viene definita in NVMe su TCP? Fondamentalmente, ogni coda è mappata su una connessione TCP bidirezionale e il trasferimento dati comandato viene solitamente elaborato da un contesto dedicato, sia che si trovi nel software o in qualche modo nell'hardware. Quindi, nel diagramma qui, abbiamo sul lato sinistro l'host che ha un'interfaccia di accodamento per il trasporto NVMe stesso, ha una coda di invio e una coda di completamento. Tutti gli invii e i completamenti vengono gestiti in quello che chiamiamo thread I/O NVMe-TCP o in un contesto I/O che viene attivato dall'host che emette I/O o dalla rete, solitamente completando I/O o ricevendo dati.

02:24 GS: La stessa immagine si verifica sul lato destro con il controller e, fondamentalmente, questi sono i contesti responsabili del trasferimento dei dati tra l'host e il controller. Quindi ciascuna di queste code in realtà è mappata su CPU dedicate di solito, ma non necessariamente, potrebbero essere di più, potrebbero essere di meno in realtà, ma il punto è che non esiste una serializzazione a livello di controller, quindi ogni coda non dipende da un nodo condiviso nastro con altre code, il che lo rende estremamente parallelo. E il diagramma qui è un diagramma standard che è stato mostrato prima riguardo all'insieme di code, c'è anche la coda di amministrazione, tra l'host e il controller, e poi una serie di code I/O, coppie di code che sono code di invio e di completamento . In NVMe/TCP, sostanzialmente ciascuna di queste code è mappata su una connessione TCP bidirezionale. Quindi, se osserviamo i contributi di latenza, ne abbiamo alcuni che potrebbero insinuarsi. Prima di tutto, nella serializzazione, ma in NVMe/TCP, è piuttosto leggero, è in base alla coda, quindi è scalabile abbastanza bene.

Questo articolo fa parte di

03:43 GS: Cambio di contesto. Quindi, ne abbiamo almeno due forniti dal driver stesso, copia della memoria, di solito pezzi d'antiquariato, siamo in grado di eseguire zero copie come driver a livello di kernel. Su RX, tuttavia, eseguiamo la copia della memoria, non è un fattore enorme, ma con un carico molto, molto elevato, può contribuire a un'ulteriore latenza. Gli interrupt (interruzioni NIC) hanno sicuramente un impatto notevole, consumano CPU e incidono sulla scalabilità di quanto può ottenere una singola coda. Abbiamo LRO e GRO o la moderazione degli interrupt adattivi può mitigarlo un po', ma la latenza potrebbe essere meno coerente. Poi abbiamo l'overhead del socket, esiste ma in realtà non è enorme, è piuttosto veloce dato che i socket sono piuttosto incontrastati in un'interfaccia multi-coda, ma in piccoli I/O potrebbe avere un impatto. L'affinità tra interrupt, applicazioni e thread I/O può sicuramente avere un impatto se non configurata correttamente e ne parleremo più approfonditamente. Inquinamenti della cache, ovviamente, derivanti dalla copia della memoria, ne abbiamo alcuni, ma non è qualcosa di eccessivo nei core delle CPU moderne che dispongono di cache sufficientemente grandi.

05:15 GS: