Mise à niveau de NVMe/TCP

May 22, 2023

Téléchargez la présentation :Mise à niveau de NVMe/TCP

Je m'appelle Sagi Grimberg. Je suis CTO et co-fondateur de Lightbits Labs, et j'ai été le co-auteur de la spécification standard NVMe sur TCP.

Nous allons donc commencer par une courte introduction. Qu’est-ce que NVMe sur TCP ? NVMe sur TCP est la liaison de transport standard qui exécute NVMe au-dessus des réseaux TCP/IP standard. Il suit la spécification NVMe standard qui définit l'interface de file d'attente et l'interface multi-file d'attente qui s'exécute juste au-dessus des sockets TCP/IP. Il dispose du jeu de commandes NVMe standard, il se trouve qu'il est encapsulé dans ce que nous appelons les PDU NVMe/TCP qui mappent les flux TCP. Ainsi, dans le diagramme ici, nous avons essentiellement l'architecture NVMe, des architectures de base qui définissent l'administrateur, les E/S et d'autres jeux de commandes.

01h14 SG : En dessous, nous avons NVMe over Fabrics qui définit les capsules, les propriétés et la découverte. Et NVMe sur TCP définit essentiellement des fonctionnalités et une messagerie supplémentaires, ainsi que le mappage de transport vers la structure sous-jacente elle-même, qui dans notre cas est TCP/IP.

Alors, comment une file d'attente est-elle traitée par NVMe sur TCP ou comment est-elle définie dans NVMe sur TCP ? Fondamentalement, chaque file d'attente correspond à une connexion TCP bidirectionnelle et le transfert de données commandé est généralement traité par un contexte dédié, que ce soit dans le logiciel ou d'une manière ou d'une autre dans le matériel. Ainsi, dans le diagramme ici, nous avons sur le côté gauche, l'hôte qui a une interface de mise en file d'attente avec le transport NVMe lui-même, une file d'attente de soumission et une file d'attente d'achèvement. Toutes les soumissions et les achèvements sont gérés dans ce que nous appelons un thread d'E/S NVMe-TCP, ou dans un contexte d'E/S qui est déclenché soit par l'hôte qui émet les E/S, soit par le réseau, complétant généralement les E/S ou recevant données.

02h24 SG : La même image se produit sur le côté droit avec le contrôleur, et fondamentalement, ce sont les contextes qui sont en charge du transfert de données entre l'hôte et le contrôleur. Ainsi, chacune de ces files d'attente est généralement mappée sur des processeurs dédiés, mais pas nécessairement, cela pourrait être plus, cela pourrait être moins en fait, mais le fait est qu'il n'y a pas de sérialisation à l'échelle du contrôleur, donc chaque file d'attente ne dépend pas d'un serveur partagé. bande avec d'autres files d'attente, ce qui le rend extrêmement parallèle. Et le diagramme ici est un diagramme standard qui a été montré précédemment sur l'ensemble des files d'attente, vous avez également la file d'attente d'administration, entre l'hôte et le contrôleur, puis un ensemble de files d'attente d'E/S, des paires de files d'attente qui sont des files d'attente de soumission et d'achèvement. . Dans NVMe/TCP, chacune de ces files d'attente est mappée à une connexion TCP bidirectionnelle. Donc, si nous examinons les contributions à la latence, nous en avons un certain nombre qui pourraient s'infiltrer. Tout d'abord, dans la sérialisation, mais dans NVMe/TCP, c'est assez léger, c'est par file d'attente, donc ça évolue. assez bien.

Cet article fait partie de

03h43 SG : Changement de contexte. Ainsi, nous en avons au minimum deux contribués par le pilote lui-même, une copie de mémoire, généralement des antiquités, nous sommes capables de faire zéro copie en tant que pilote au niveau du noyau. Cependant, sur RX, nous effectuons une copie de mémoire, ce n'est pas un facteur énorme, mais en cas de charge très, très élevée, cela peut contribuer à une latence supplémentaire. Les interruptions - les interruptions de la carte réseau - ont certainement un impact, elles consomment du processeur et ont un impact sur l'évolutivité de ce qu'une seule file d'attente peut réaliser. Nous avons LRO et GRO ou la modération adaptative des interruptions peut atténuer un peu cela, mais la latence pourrait alors être moins cohérente. Ensuite, nous avons la surcharge des sockets, elle existe mais ce n'est vraiment pas énorme, c'est assez rapide étant donné que les sockets sont assez peu contestés dans une interface multi-files d'attente, mais dans les petites E/S, cela pourrait avoir un impact. L'affinité entre les interruptions, les applications et les threads d'E/S peut certainement avoir un impact si elle n'est pas configurée correctement, et nous y reviendrons plus en détail. Les pollutions du cache, évidemment, résultant de la copie de la mémoire, nous en avons, mais ce n'est pas quelque chose de si excessif dans les cœurs de processeur modernes qui ont des caches suffisamment grands.

05h15 SG :