Un thread GPU n'a rien à voir avec un thread de Xeon: il faut imaginer une seule instruction SSE qui est exécutée des centaines de fois en parallèle sur des données différentes par des unités de calcul séparées. Du coup, pour être efficace l'accélération par GPU actuel impose un algorithme sans "if". Dès lors qu'il y a un "if", les threads sont sérialisés dans un "groupe" et du coup la puissance devient limitée.
Il y a donc des domaines candidats "faciles" comme faire trouver le port de sortie pour un paquet et des domaines pas adaptés comme faire tourner BGP. Le GPU est adapté pour calculer des clé en brute force , mais beaucoup moins efficace pour crypter/décrypter un bloc (byte n+1 dépenden de byte n -> difficile de mettre au point des algos parallèles: la pratique montre que coût transfert mémoire + encryptage/décryptage fait que c'est plus rapide en Xeon!). FF -----Message d'origine----- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Stephane Bortzmeyer Envoyé : vendredi 25 février 2011 22:36 À : Jerome Benoit Cc : frnog@frnog.org Objet : [FRnOG] Re: RFC 6115: Recommendation for a Routing Architecture On Fri, Feb 25, 2011 at 10:26:38PM +0100, Jerome Benoit <jerome.ben...@grenouille.com> wrote a message of 39 lines which said: > C'est dans les cartons, regardes ce qu'on peut faire avec un GPU > récent pour accélérer les recherches dans la table de routage. Si c'est une allusion à PacketShader (voir par exemple <http://www.bortzmeyer.org/packetshader.html>), alors, il s'agit bien de "Forwarding plane" et pas de "Control Plane" et Thomas Mangin a donc raison, ce n'est certainement pas une aide pour BGP. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
