 C3T ou par email at hello at C3lingo.org. Alors, c'est un plaisir de présenter Paul Emmerich qui va parler ici, démystifier l'écart réseau. Il est étudiant en PhD at L'Erste de Munich. Il fait plein de trucs sur les réseaux et j'espère qu'il va rendre l'écart réseau un petit peu moins mystérieux pour nous. Accueillez le chaleureusement. OK. Merci. Donc, comme l'introduction le disait, je suis étudiant en PhD. Je travaille sur du paquet de processing, sur de transmission de paquets. Je fais beaucoup de choses à propos de l'optimisation. Je regarde qu'est-ce qui rend les items lents, rapides. Je travaille sur mon produit mounjen. J'ai d'ailleurs à voir une démo ce samedi. Mais ici, bon, je dois parler très vite parce que j'ai beaucoup de contenu à couvrir. J'espère que vous en arriverai à suivre. On va parler de cartes réseaux. Vous avez tous vu des cartes réseaux. Voilà, ça, c'est une cartes réseau classique 10 gigabit. En voilà une qu'un peu plus rapide. Celle-ci fait 20, 30, 40, 100 gigas. Vous avez des cartes réseaux. Vous voulez brancher dans votre serveur, etc. Vous le démarrer, vous lancer un serveur web et vous observer des photos de chat ou des vidéos de chat. Il y a bien sûr toute une stack de protocoles réseaux qui doit marcher pour faire ça. Mais moi, tout ce qui m'intéresse, c'est les couches les plus basses. Je m'en fiche de TCP. Bon, je comprends quand ça marche, mais ce n'est pas du tout ma recherche. Moi, je peux regarder vraiment au niveau des paquets individuels. Et le plus haut dans mon monde, c'est peut-être des adresses IP, plutôt des identifiants des adresses Mac. Alors, moi, ce qui m'intéresse dans ces couches basses, c'est que la plupart des gens implémentent à peu près tout sur HTTP d'un jour, mais ça vous surprendra peut-être d'apprendre que tout ne tourne pas sur HTTP. Il y a encore énormément de softwares qui marchent sur des choses à plus bas niveau. Il y a énormément de choses qui sont difficiles à faire bouger de systèmes propriétaires à des systèmes ouverts. Par exemple, des routeurs, des switch, des firewalls. Si vous voulez faire de la virtualisation de ces trucs-là, ou si vous voulez échanger, les améliorer, c'est des sujets dans lesquels on n'est arrivé que dans ces dernières années. Alors, disons qu'on veut développer notre propre application à bas niveau pour modifier des paquets qui font je ne sais quoi. Donc, on a un exemplier d'infrastructure réseau et je vais parler de cette application comme démo pour cette présentation. Cette application modifie des paquets. Donc, on peut voir cette application reçoit des paquets depuis plusieurs interfaces réseaux, fait des trucs dessus et les modifient, les routes et ensuite les renvoi sur une autre carte réseau ou peut-être la même ou plusieurs. C'est ce que font ces deux genres d'applications. Et donc, ça veut dire que cette application réfléchit au niveau de paquets individuels, pas sur un stream, un flux de paquets et prendre une décision sur chaque paquet qui passe. Alors, vous voulez construire cette application, vous allez sur Internet, vous vous cherchez comment construire une application qui transmet des paquets et on vous dit, bon, il y a une API, l'API des Sockets, ça vous permet de construire vos programmes et vous construisez votre application au-dessus de cette API des Sockets qui est au-dessus de système d'exploitation, qui est au-dessus du driver, du pilote, qui est au-dessus des cartes réseaux. Sauf qu'en fait, c'est pas ça. Entre cette application et le système d'exploitation, il y a une faille gigantesque entre le user space et le kernel space et il faut que vos paquets passent de l'un à l'autre. Et vous vous demandez peut-être pourquoi je dis que c'est quelque chose d'important, pourquoi est-ce que je montre ce creux comme énorme. Et bien tout simplement parce que quand vous voulez envoyer vos photos de chat, vous allez copier des gros morceaux de données, des gros paquets de votre user space à votre kernel space. Vous allez devoir copier chaque octet de votre vidéo de chat, la file au kernel et le kernel ensuite en pouvoir la donner au driver. Mais il faut que votre application soit capable de gérer les pire cas avec plein de petits paquets ou quelques très gros paquets. Et ça, c'est parce que notre API est gérée au niveau des paquets et pas au niveau des octets. Si on parle de performance parce que moi, c'est mon truc. La performance en paquets par seconde sur un lien de 10 gigabits par seconde, combien est-ce que de paquets on peut mettre sur ce lien par seconde à peu près 15 millions? Mais bon, 10 gigabits, c'est tellement la ligne dernière ça. Si on est connecté par exemple ici au congrès, on est connecté à 100 gigabits, on peut envoyer à peu près 150 millions de paquets par seconde. Alors combien de temps ça nous laisse si on a un CPU? On a un CPU à 3 gigahertz avec 15 mega octets par seconde. Ça fait à peu près 200 cycles disponibles par paquet. Alors on ne veut pas, on a rassurement plusieurs corps, mais on aura aussi plusieurs cartes réseaux et des liens de plus en plus rapides. Donc ça veut dire que la cible performance de cette application, c'est à peu près 5 à 10 mega octets par corps simplement pour transmettre le paquet. C'est juste pour le recevoir et le renvoyer à l'identique. Tout le reste des choses qu'on peut faire, c'est du temps en plus. Donc on ne veut vraiment pas avoir un coût de qualité de performance pour recevoir ou pour envoyer. Alors ces chiffres, ça donne à peu près 5 à 10 megabits par seconde par corps, simplement pour faire de la transmission. Et du coup, ça veut dire que le temps qui, à notre échelle, le temps que ça met pour transmettre les données du carnel à l'utilisateur ou vice-versa, c'est très, très long. Une machine avec un seul cœur, avec l'interface de la paysquette, c'est à peu près 0,3 millions de paquets par seconde, ce qui est très lent. Si on fait cette transmission de paquet avec l'ali-pk, on a près un million de paquets par seconde pour un corps. Donc on peut résoudre ça en mettant l'application directement dans le carnel. On réécrit l'application comme un module de carnel. Alors ça peut sembler être une aberration d'écrire du code carnel pour quelque chose qui fait simplement du processus de paquet et qui va déchiffrer des paquets arbitraires. Mais ce n'est pas forcément une idée si aberrante, que ce soit Microsoft Windows ou les derniers versions du carnel Linux. Tout le monde fait ça. Linux a un cache dans le carnel qui existe exactement pour permettre de faire ce genre de choses. Donc ce n'est pas une idée complètement aberrant ou nouvelle. Alors quand on veut bouger notre application dans le carnel, il y a plein de nouveaux problèmes. C'est plus dur à développer. La plupart de nos outils ne fonctionnent pas. On est plus ou moins obligé de programmer en C, même si on n'a pas forcément envie. Et notre application dans le carnel, si elle est de box, peut être très problématique. Mais bon, on est là pour parler de performance. Alors performance dans le carnel, on arrive à peu près à du 5 à 10 Mbps par corps pour simplement transmettre. Ça veut dire que le temps pour recevoir un paquet dans le carnel Linux, c'est à peu près 500 cycles. Ça veut dire que 500 cycles juste pour recevoir le paquet. Mais ça ne suffit pas parce qu'il faut derrière le renvoyer. C'est un petit peu plus rapide, mais bon, c'est 440 cycles. Et sachant qu'on a un budget à peu près de 300 à 800 cycles par paquet à 3 GHz. Mais il faut rajouter le temps pour allouer de la mémoire, initialiser, libérer la mémoire. Souvent, ça va être des SK Buff, le type dans le carnel Linux. Ça, c'est à peu près 400 cycles. Donc, si on regarde une application du monde réel, Opus V Switch, qui est une implementation d'openflow sur des ports physiques, on est à peu près à 200 cycles par paquet, mais avec l'overhead du carnel, on est à peu près à presque 1000 cycles. Et du coup, on est à peu près à 2 millions de paquets par seconde, ce qui est quand même plus rapide que ce qu'on avait en user space. Mais bon, c'est quand même toujours un petit peu lent. Alors, le sujet chaud du moment, je ne vais pas en parler ici, mais bon, c'est XDP qui résout pas mal de ses problèmes dans le carnel Linux. Mais bon, c'est un sujet complètement à part. Je n'ai pas le temps de parler de ça ici. Donc, on ne parlera pas d'XDP aujourd'hui. Alors, est-ce qu'on peut faire des choses quand même en user space ? On a bougé, ça ne marchait pas de bouger des choses de notre application dans le carnel space. Est-ce qu'on peut faire l'inverse ? Bougez plus de choses du carnel space dans user space. Alors, en peu, il y a des applications qu'on peut linker dans le user space avec un module carnel dédié et la librairie et le carnel, enfin le module carnel communique une façon particulière qui permet de communiquer plus vite. Ça, ça vous donne une API plus rapide. Et quand on fait les choses comme ça, vous pouvez voir que l'OS lui-même n'est connecté à rien. Il n'a pas besoin de toucher au cartrézo. C'est notre module de carnel à nous qui fait ça. Donc, il y a trois frameworks pour ça. Par exemple, il y a Netmap, Netmap, PF Ring de C et je l'ai arrêté le dernier. Mais bon, ça vient avec certains problèmes. Ça, on a une API qui n'est pas standard. Il faut charger vos propres modules de carnel. La plupart d'entre eux nécessitent d'avoir des patchs sur les drivers eux-mêmes. Bien sûr, ce module a besoin d'avoir un accès dédié à la carterse. Donc, vous ne pouvez pas avoir d'applications traditionnelles qui utilisent la carterse en même temps. Donc, vous perdez aussi l'accès à toutes les fonctionnalités du carnel normal. Ça, ça peut être un petit peu embêtant. Et il n'y a pas forcément un support pour... Donc, comme c'est le framework qui parle directement à une carterse, il va falloir parler généralement à une carterse par une carterse. Parfois, il supporte quelques familles de carterse, mais généralement, ils sont conçus pour une carterse en particulier, un modèle de carterse en particulier. Alors, si on avait une approche encore plus radicale, parce que là, on a toutes ces questions de latence, et si on se passait du carnel complètement et qu'on était tout dans une application Azure Space, on met le carnel dans l'application, le carnel accède directement à la carterse. Donc, il fait du MMA pour avoir accès à la mémoire directement, et on a juste besoin de jongler nos pointeurs correctement. Et avec ça, on a tout dans l'application. On a enlevé les pilotes, les drivers du carnel lui-même. Et ça, c'est très, très rapide. Et ça, ça permet à l'application aussi d'implementer des fonctionnalités un petit peu oscures ou un petit peu custom supportées par votre cartes réseaux. Alors, je ne suis pas le premier à faire ça. Il y a deux frameworks qui sont assez connus qu'il faut ça. Il y en a un, c'est DPIDK qui est assez, assez gros. C'est un projet d'Inux Foundation. Leur but, c'est de supporter toutes les cartes réseaux rapides. Donc, ça veut dire que tous les gens qui ont des cartes réseaux s'intéressent quand même à DPIDK. Le deuxième, c'est SNAP. C'est un projet que je trouve intéressant. Bon, ça marche pas si tout à fait, ça marche pas si tout à fait pareil. C'est pas implémenté, c'est en C, c'est implémenté en Lua, qui est un langage de script qui s'interface avec le C. Ok. Alors, quel problème ça résolu ? Un problème, c'est qu'on a toujours une API pas standard. On a toujours besoin d'avoir un accès exclusif à la carte réseau. Et puis, il faut toujours un framework qui supporte la carte réseau elle-même. C'est-à-dire que chaque modèle de carte réseau qu'on veut supporter, on doit l'ajouter, on doit y créer du code dessus. DPIDK supporte à peu près toutes les cartes à plus de 10 GB par seconde. Mais c'est une implémentation par modèle de carte réseau. Et on a quand même un support limité pour les interruptions. Les interruptions ne sont pas utiles quand vous arrivez à plus d'à peu près un dixième de millions de paquets par seconde. Et bien sûr, vous perdez également l'accès à toutes les fonctionnalités normales du kernel. Mais bon, à quoi ça sert le kernel ? Qu'est-ce que le kernel fait pour nous ? Le kernel a quand même beaucoup de drivers qui marchent très bien, des drivers très matures. Il a aussi des implementations qui marchent réellement de protocoles comme TCP, par exemple. Parce que si vous implementez vos propres TCP, ça ne marchera pas aussi bien. C'est sûr, c'est très facile de se planter. Mais bon, qu'est-ce que le kernel a fait d'autre pour nous, à part des drivers et à part d'implementer son TCP ? Bon, quelques petits trucs quand même. Donc il y a les interruptions. Il y a des choses qui ne nous importent pas trop quand construit une autre application de process de paquets. Parce que pour la plupart d'entre elles, c'est quand même des fonctionnalités de très haut niveau. Mais c'est quand même beaucoup de fonctionnalités qu'on perd. Par exemple, construire une stack TCP sur ces frameworks-là, c'est un problème qu'on n'a pas encore vraiment résolu. Ok, alors, on a perdu ces fonctionnalités, mais bon, on s'en fiche un peu de toute façon. Ce qu'on vous laisse, c'est de la performance. Si on regarde la performance, on voulait 300 à 600 cycles par paquet. Et qu'est-ce qu'on a disponible avec dpdk ? On a à peu près 100 cycles pour faire passer le paquet dans toute la stack, que de la réception au processing, non pas le processing, pardon, mais éventuellement le caching, et le renvoyer à la carte réseau. On a à peu près 100 cycles. Dpdk est un petit peu plus rapide que les autres, parce qu'il y a beaucoup beaucoup d'instructions magiques, SSD, AVX, etc., qui rend les choses plus rapides, mais il est vraiment très très rapide. Alors, bon, dans un mon scénario réel, donc quand j'en parlais pour OpenVswitch d'avoir d'à peu près 2 millions de paquets par seconde, si on le compile avec dpdk, quand on a quelques flags magiques pendant la compétition, on arrive à un OpenVswitch qui utilise dpdk, et ça, ça me donne quelque chose d'à peu près 6 à 7 fois plus rapide, à peu près 13 millions de paquets par seconde sur le même processeur qu'on avait avant. Donc pas mal. Joli gain de performance, d'où est-ce que ces gains de performance viennent ? Eh bien, il faut voir que c'est quand même des gains de performance comparés au kernel, pas comparés à la paysquette. Parce que quand les gens parlent de zéro copie, je trouve que c'est un terme un peu stupide, parce que le kernel fait des copies de toute façon. Donc les optimisations zéro copies dans le kernel, c'est pas très bien. La performance vient principalement du batching, on va batcher par 16 ou 64 paquets typiquement, et puis beaucoup moins de verts de mémoire, parce qu'il y a beaucoup moins d'allocations à faire. Parce que dpdk a un système beaucoup plus simple de gestion de la mémoire, et du coup il n'y a pas besoin de faire tout ça. Ok, donc la question qui se pose directement après ça, c'est est-ce qu'on peut construire notre propre driver user space ? Oui, pourquoi pas ? Pourquoi ferait-ce ça ? Pour comprendre déjà comment tout ça marche, pour comprendre comment est-ce que les frameworks marchent, pour comprendre comment est-ce que ce framework de gestion des paquets fonctionne. Dans le monde d'académie, il y a beaucoup de gens qui s'intéressent à ce genre de questions, et moi quelque chose qui me déplore, c'est que les gens traitent souvent leur carte réseau comme des boîtes noires magiques qui juste fonctionnent, et si on regarde dpdk par exemple, ils prennent une approche différente, il y a des dizaines, des centaines et milliers de lignes de code pour chaque driver. Donc ça fait un fichier d'à peu près 3 000 lignes de code avec énormément de magiques que personne n'a envie de lire pour un driver. Donc la question qui se pose là-dessus, c'est est-ce que c'est vraiment dur d'écrire son propre driver ? Il s'avère qu'en fait ce n'est pas si compliqué que ça. J'ai réussi à en écrire un mois à environ 1000 lignes de C, et avec ça je peux faire tourner quelques applications, ça m'a pris quelques jours, moins de deux jours pour écrire le système, et deux jours de plus pour avoir une performance raisonnable. Donc moi j'ai écrit ce driver sur des cartes Intel iXGB, c'est une famille de cartes Rézot qui, la plupart ont des connexions 10 GB, ça a sur la cartes Rézot un CPU Xeon, et la façon, moi la façon dont je pense ça c'est que, un autre qui m'intéresse beaucoup pardon sur ces cartes Rézot, c'est que la data sheet est disponible publiquement. Donc ça rend les choses très faciles quand on veut créer un driver pour ces cartes-là, et l'autre chose qui est très bien c'est qu'il y a très très peu de magies cachées dans le firmware de la carte. Beaucoup de cartes Rézot ont tendance à cacher énormément de fonctionnalités dans le firmware, et on a pays qui veut juste déchanger des messages. Cette cartes Rézot-là ne fait pas ça, et moi je trouve ça très très intéressant. Donc comment se construire un driver en user space en quatre étapes simples ? La première chose à faire c'est vous enlever le driver qui est déjà là, parce que vous voulez pas qu'il utilise la carte Rézot. La deuxième chose c'est vous mapez la mémoire du MMO PCI dans votre adresse space d'adressage user space. Ensuite, vous trouvez les adresses nécessaires pour communiquer avec ça, pour faire du DMA, et ensuite vous avez juste à écrire le driver. Donc la première chose à faire c'est de trouver où est le périphérique que vous voulez utiliser. Toutes cartes PCI, PCI ou PCI Express à une adresse, donc ça c'était l'adresse. Donc avec ça je peux décharger le driver et le videur ne peut s'intéresser à cette carte-là. Donc avec ça, le système d'opération ne sait pas que c'est une carte Rézot, tout ce qui c'est du PCI. Donc maintenant on peut écrire notre application. Il ouvre ce fichier magique dans 6FS, ce fichier magique c'est juste un M-Map, un M-Map d'une région de mémoire, et c'est ma paix aux entrées sorties de la carte PCI. Avec ça, tous les registres sont disponibles, j'expliquerai ce que ça veut dire dans juste une seconde. Si vous regardez la datasheet de votre carte Rézot, il y a des dizaines et des centaines de pages, et vous pouvez voir tous les registres que cette carte Rézot a. Avec ça, vous pouvez modifier différentes options de la carte, dans le code, ça ressemble à ça. Avec ça, vous pouvez, par exemple, utiliser cet offset pour accéder à un offset en bit, le 7e bit, c'est un bit qui se dit que la diode doit clignoter. Si vous le mettez à un, la diode va se mettre à clignoter quand il n'y a pas qui qui passe. Vous ne pouvez pas simplement écrire dans cette zone de la mémoire. Vous devez utiliser volatiles pour que les accès mémoires soient directement flechés pour faire la mémoire de la carte Rézot. Quand vous écrivez, vous n'écrivez pas vraiment de la mémoire, c'est juste des commandes que vous envoyez à la carte. C'est une technique très commune quand vous les communiquez avec des périphériques. Alors, une chose à noter, c'est que comme cette mémoire ne peut pas être cachée, ne peut pas être mis en cache, parce que chacun de ces accès à la mémoire, c'est une commande qu'on va envoyer là-bas. Si les accès mémoires sont cachés, les commandes soient reflétés. Parfois, ce ne peut pas être même des centaines de secondes, ce qui est complètement beaucoup trop long. Donc, on utilise volatiles pour éviter ça. Alors, comment est-ce qu'on peut manipuler ces paquets ? Les paquets arrivent par DMA. Donc, bien évidemment, ce serait possible d'écrire une carte Rézot qui utilise uniquement une mémoire IMAP, mais c'est assez embêtant. Du coup, les devices PCI Express pour communiquer, en plus de l'accès à la mémoire, c'est de faire des accès initiés par la carte Rézot. C'est-à-dire que la carte Rézot peut écrire des adresses arbitraires dans la mémoire principale, dans la RAM. Donc, cette carte a ce qu'on appelle une interface de réception des paquets, et ça permet d'écrire dans la mémoire. Il y a des paquets de scale à plusieurs corps, puisque vous avez plusieurs queues, une par coeur de processeur. Ce que fait la carte Rézot pour ça, c'est qu'elle va faire un hash des paquets qui arrivent sur les adeurs du protocole. Et ça, ce n'est pas spécifique aux cartes Rézot. La plupart des cartes PCI Express fonctionnent là-dedans, par exemple les cartes graphiques, ou d'autres choses ont plusieurs queues, et une par processeur. Donc, si on regarde, c'est que je vais m'intéresser en particulier à la famille XGB, mais la plupart des cartes fonctionnent comme ça. Donc, c'est des buffers circulaires qui sont remplis avec des descripteurs de DMA. Ce descripteur, c'est juste des pointeurs qui pointent à un endroit là-bas, et là-bas, on a plus de données. Il y a 8 octets de pointeurs physiques et 8 octets d'informations, comme par exemple, pour dire ce paquet a été déplacé, ou d'autres informations, d'autres métats à donner, comme ça. Ça, ça permet de traduire les adresses virtuelles en adresses physiques en utilisant le device dans ProcFS, ProcSelfPayMap, ça permet de faire la traduction. Et la chose suivante, c'est qu'on a du coup une queue de descripteur en DMA auquel on peut accéder par DMA. Cette queue, elle est circulaire, mais cette queue n'est pas circulaire, il y a une queue qui pointe sur des endroits en user space, et ça ressemble à ça. À gauche, vous voyez que vous avez notre anneau de pointeur, et à droite, vous voyez que vous avez un pool de mémoire vers lequel pointe les pointeurs qui sont dans cet anneau. La raison de faire ça, c'est que ces descripteurs doivent être dans des zones contigues en mémoire, et si vous assumez que votre mémoire est contigu, et que vous avez un bug là-dedans, et que vous commencez à écrire dans les mauvais zones, vous avez écrit par exemple sur votre file-système, et vous avez tué votre file-système, et c'est pas bon du tout. Donc, si vous utilisez des pages, des pages très grosses, comme par exemple généralement ça suffit à résoudre ce problème parce que vous n'avez pas besoin d'espace mémoire si gros que ça. Donc, pour recevoir des paquets, on a besoin de mettre en place notre système. Vous pouvez indiquer où est cette anneau, ensuite vous le remplissez avec des pointeurs vers cette mémoire, mais pour l'instant elle est encore vide. Vous mettez le pointeur de tête, le pointeur de queue, pour indiquer que la queue est pleine, parce que l'actuelle la queue est pleine de paquets, on n'a encore rien processé du tout. Ensuite, vous créez votre premier descripteur, et dès que la queue va recevoir un paquet, elle va incrémenter le pointeur de tête, va mettre un bit de statut pour dire que ce paquet doit être transmis à mémoire, a été transmis à mémoire. La raison pour ça, c'est parce que lire tous les pointeurs par AIO directement, c'est beaucoup trop lent. Mais par contre, les bits de statut comme ça, c'est quelque chose qui est optimisé par différents niveaux de cache, et ça, ça rend l'accès à ces bits-là beaucoup plus rapide que de lire les paquets eux-mêmes. Après ça, on fait plusieurs choses qui peuvent être utiles. Il y a cette fausse idée que si on reçoit un paquet, c'est une interruption, et que dans l'interruption on va processer le paquet. Ce n'est pas du tout comme ça que ça marche en fait. Si on faisait ça, on a l'impression qu'on tigue, continue, et on aurait quand même besoin de pouler la queue des paquets pour voir ce qui arrivait, plus vite. Donc à la place, on pool on va pool la queue des paquets, ou plus précisément le bit de statut des paquets qui va faire. Quand on en a en process le paquet et ça, ça nous permet de garder la queue 100% utilisée. On a besoin de lire ce paquet de ce bit de statut que tous les 100 paquets par exemple. Ça, ça permet d'éviter d'avoir rentré dans cette boucle tout le temps. Alors, qu'est-ce qu'on peut faire maintenant ? Pour transmettre les paquets, c'est à peu près pareil. Sauf qu'il y a beaucoup, beaucoup de codes pour initialiser le tout qui est très ennuyeux. Bon, pour être tout à fait franc, vous copiez le code de la data sheet et ça marche. Mais avec ça, il y a quand même quelques idées de choses qu'on peut vouloir faire ou vouloir tester. Par exemple, on peut regarder qu'est-ce qu'on peut faire là-dedans qui rend les choses plus rapides que dans le kernel, côté performance. On peut regarder les fonctionnalités un petit peu obscures, ou des fonctionnalités de sécurité par exemple, l'offloading de IPsec. Dans la sécurité, il y a des choses intéressantes. Par exemple, il y a évidemment cette question de sécurité qui est quand même pointue. Est-ce que c'est bien d'avoir tout ça dans user space ? Parce que si, ce qu'on peut faire pour limiter ça, c'est une fois qu'on a mis en place le mapping de mémoire, on peut révoquer les privilèges. Ou on a un driver qui est quand même sûr, qui n'est pas dangereux et qui est en user space, parce que les autres cartes ou les autres process n'ont pas accès à cette mémoire. Alors bien sûr, ce qu'on peut vouloir faire dans ce genre de code, c'est aussi supporter d'autres modèles de cartes réseaux ou d'autres langages de programmation. En conclusion, jeter un œil à Exy, c'est sur GitHub, c'est sous licence BSD. Ce qui est cool, c'est que c'est très court, très simple, n'ayez pas peur, c'est moins de 1000 lignes de code de C pour le framework entier, et comme c'est quand même le langage le plus commun, le langage exfondé, le plus commun. Dans votre langage de prédiction, ça devrait être plus simple. Le driver, c'est facile, il ne faut pas qu'il fasse peur, vous pouvez les écrire n'importe quel langage, et vous n'avez pas besoin d'écrire de code carnel. Alors, vous n'utilisez pas les pilotes, les nukes, donc est-ce que ça c'est tout les nukes, c'est ce que vous essayez sous d'autres systèmes d'exploitation. Je n'ai pas vraiment essayé d'autres systèmes d'exploitation, un des attraits pour moi, c'est que je peux utiliser LibEvent parce que LibEvent a plein de fonctionnalités pour faire de la notification etc. Si vous voulez voir des pilotes qui font avec uniquement du mapping de l'émoire, vous pouvez regarder des PDK qui fait ça aussi sur d'autres plateformes. Autre question, un petit peu plus éloigné du talk, qu'est-ce que vous pensez des smartnicks, des cartes réseaux où on pense à mettre un CPU sur la cartes réseaux elle-même pour faire tourner OpenVswitch dessus. La réponse, alors, j'ai regardé un petit peu ce genre de choses, j'ai travaillé avec des FPGA, je pense que c'est un sujet extrêmement intéressant, mais il y a des compromis à faire. Ces smartnicks, elles arrivent avec des restrictions, elles ne peuvent pas forcément faire les choses tout à fait pareil. C'est très intéressant sur le plan la performance, ça a des énormes potentiels côté performance, mais je pense que, du point de vue polyvalence, c'est plus intéressant de tout faire avec juste des processeurs génériques. Alors, est-ce qu'on peut comparer la performance des drivers user space à XTP ? La réponse, c'est un petit peu plus rapide, une chose de noté à propos de XTP, XDP, pardon, c'est que c'est quelque chose qui est encore en travaux, encore en progress, et il y a beaucoup de restrictions. Vous ne pouvez pas tout faire, vous êtes restreint à certaines des API, tout comme certains frameworks que vous contraignez, à certains langages, par exemple, le DOA, XDP vous contraigne à certaines API. Donc ça, ça peut vous donner des restrictions qui ne sont pas forcément intéressantes pour vous. Et aussi, XDP requiert non pas des patchs sur le driver, mais des modules spécifiques dans le kernel. Et XDP manque encore de sa fonctionnalité, par exemple, envoyer le paquet sur une autre carte réseau. Donc avec XDP, il y a quand même des fonctionnalités qui sont très intéressantes, comme par exemple, on peut prendre les paquets et les donner à la carte d'effet, ça c'est un use case, une question très pratique de XDP. En résumé, XDP est un petit peu plus lent, mais c'est quand même très rapide. Et bien, vous avez écouté cette traduction en français de cette présentation pour démystifier les cartes réseaux. Cette présentation était par Paul Emmerich.