Atualizando o NVMe/TCP

May 22, 2023

Baixe a apresentação:Atualizando o NVMe/TCP

Meu nome é Sagi Grimberg. Sou CTO e cofundador do Lightbits Labs e coautor da especificação padrão NVMe sobre TCP.

Então, começaremos com uma breve introdução. O que é NVMe sobre TCP? NVMe sobre TCP é a ligação de transporte padrão que executa NVMe sobre redes TCP/IP padrão. Ele segue a especificação NVMe padrão que define a interface de fila e a interface multifila que é executada apenas sobre os soquetes TCP/IP. Ele tem o conjunto de comandos NVMe padrão, mas está encapsulado no que chamamos de PDUs NVMe/TCP que mapeiam os fluxos do TCP. Então, no diagrama aqui, temos basicamente a arquitetura NVMe, arquiteturas centrais que definem o admin, I/O e outros conjuntos de comandos.

01:14 horário de Brasília: Abaixo disso temos NVMe sobre Fabrics que define cápsulas, propriedades, descoberta. E o NVMe sobre TCP basicamente define recursos e mensagens extras, e também o mapeamento de transporte para a própria estrutura subjacente, que em nosso caso é o TCP/IP.

Então, como uma fila é processada pelo NVMe sobre TCP ou como é definida no NVMe sobre TCP? Basicamente, cada fila é mapeada para uma conexão TCP bidirecional e a transferência de dados comandada geralmente é processada por um contexto dedicado, seja em software ou de alguma forma em hardware. Então, no diagrama aqui, temos no lado esquerdo, temos o host que possui uma interface de enfileiramento para o próprio transporte NVMe, possui uma fila de envio e uma fila de conclusão. Todos os envios e conclusões são tratados no que chamamos de thread de E/S NVMe-TCP, ou algum contexto de E/S que é acionado pelo host que está emitindo E/S ou pela rede, geralmente completando E/S ou recebendo dados.

02:24 horário de Brasília: A mesma imagem acontece do lado direito com o controlador e, basicamente, são os contextos responsáveis ​​pela transferência de dados entre o host e o controlador. Então, cada uma dessas filas geralmente é mapeada para CPUs dedicadas, mas não necessariamente, poderia ser mais, poderia ser menos, na verdade, mas a questão é que não há serialização em todo o controlador, então cada fila não depende de um arquivo compartilhado. fita com outras filas, o que a torna extremamente paralela. E o diagrama aqui é um diagrama padrão que foi mostrado antes sobre o conjunto de filas, você tem a fila de administração também, entre o host e o controlador, e então um conjunto de filas de E/S, pares de filas que são filas de envio e conclusão . No NVMe/TCP, basicamente cada uma dessas filas é mapeada para uma conexão TCP bidirecional. Então, se olharmos para as contribuições de latência, temos uma série delas que podem aparecer. Primeiro de tudo, na serialização, mas em NVMe/TCP, é bem leve, é por fila, então é escalonável razoavelmente bem.

Este artigo faz parte

03:43 horário de Brasília: Mudança de contexto. Portanto, temos no mínimo dois contribuídos pelo próprio driver, cópia de memória, geralmente antiguidades, somos capazes de fazer zero cópia como driver de nível de kernel. No entanto, no RX, fazemos cópia de memória, não é um fator enorme, mas em carga muito, muito alta, pode contribuir para latência adicional. As interrupções - interrupções NIC - são definitivamente impactantes, consomem CPU e afetam a escalabilidade de quanto uma única fila pode atingir. Temos LRO e GRO ou moderação de interrupção adaptativa que pode atenuar um pouco isso, mas a latência pode ser menos consistente. Então temos a sobrecarga do soquete, ela existe, mas na verdade não é enorme, é muito rápida, visto que os soquetes são bastante incontestados em uma interface multifila, mas em E/S pequenas, isso pode causar um impacto. A afinidade entre interrupções, aplicativos e threads de E/S definitivamente pode impactar se não for configurada corretamente, e falaremos mais sobre isso. Poluições de cache, obviamente, resultantes de cópia de memória, temos algumas, mas não é algo tão excessivo em núcleos de CPU modernos que possuem caches suficientemente grandes.

05:15 horário de Brasília: