Le 13/11/2019 à 20:00, Michel Py a écrit : >> Radu-Adrian Feurdean a écrit : >> 3) la mise a jour : imagine deja la mise a jour d'un /16 (65K entrees a >> mettre a jour), ou encore pire d'un /10 :) > Certes, mais à comparer avec ce que çà fait gagner, 85 cycles d'horloge à > chaque paquet. > Comparativement à plusieurs millions de paquets par seconde, la mise à jour > est très rare. > > En plus, la DDR c'est lent sur des accès individuels, mais pas pour les gros > blocks. DDR4 récente c'est au moins 40 GO par seconde en écriture. > Un /10 avec 8 Octets par IP çà représente 32 MO de mémoire, moins de 1ms en > théorie. Il doit bien y avoir des instructions pour gérer çà en DMA ou autres > sans même avoir une boucle bourrin. > > Michel. > Je partage un graphique, ce sont des chiffres intéressants sur les différentes grandeurs qui ont cours aujourd'hui: http://i.imgur.com/k0t1e.png (même la RAM coûte cher en perf, et c'est pas le média le plus lent !).
Ecrire dans la RAM va vite sur un bloc contigu de mémoire. Si ce n'est pas contigu, ça se transforme vite en des accès aléatoire (patricia est orienté lecture plutôt qu'être optimisé délai pour mettre à jour l'arbre). L'autre problème qui me semble important c'est qu'il y a plusieurs consommateurs (les core qui routent) et un core qui va mettre à jour la RAM, il faut donc un système qui permet de verrouiller la mémoire le temps de la mise à jour. Ces systèmes là sont lents. Mais les routes ne sont pas les seuls éléments à stocker, il y a aussi de la config, des compteurs, des interfaces, des adresses MAC, des neighbors IPv6, des pointeurs... Si avant chaque accès il faut demander l'usage exclusif de la ressource, les perfs s'écroulent. Est-ce qu'il ne faudrait pas alors avoir n copie de la FIB (et de tous les autres éléments) avec n le nombre de core ? (et en archi NUMA). Il me semble que c'est le principe de DPDK, affecter des core à une fonction unique et précise. Et qu'il soit capable de faire ce job le plus indépendamment possible, en évitant de faire du context switching. Globalement il faut se passer un maximum de la RAM, utiliser un maximum le cache (qui aujourd'hui est énorme, on peut en stocker des infos dans 24 Mo. Et même bientôt 128 Mo). Qu'en pensez-vous, est-ce que 24 Mo peut stocker 1 millions de route IPv4 (sous forme d'arbre, pas juste 1 000 000 x 4 octets !) avec les index des interfaces et les MAC des nexthop ? Quelle est la taille minimale nécessaire ? A cela il faut rajouter les problèmes de pipeline (mauvaises prédictions) ... et c'est l'enfer. Jérôme -- Jérôme Marteaux --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
