At 00:35 19.04.02, you wrote: >On Thursday 18 April 2002 18:25, Martial Guex wrote: > > > > Les constructeurs de cartes r�seaux devrait penser � cr�er un cross-bar > > parall�le au bus PCI comme par example un circuits multicouche (p.e. 4 x 64 > > bits) qui viendrait se connecter sur les cartes du cot� oppos� � la carte > > m�re. Ceci permettrait de n'utiliser le bus PCI comme un fond de panier de > > routeur sans le cross-bar et le routages des paquets devant transiter par > > d'autres cartes o� en relation avec la machine elle m�me. Bien sur cette > > situation impliquerai que les cartes int�gres des fonctions de routages et > > �ventuellement d'autres fonctons tel que la QoS. Ceci d�chargerai la > > machine mais on perdrai de la souplese. > >En fait, �a revient � d�velopper... un router !
Tiens, toi aussi tu as fait le rapprochement ! > > L'id�al serai d'avoir des cartes de > > ce type avec le firmware en open et de pouvoir travaill� �galement sur la > > m�thode utilis�e par les carte pour exploiter le cross-bar. > >Le vrai d�lire ce serait qu'un constructeur dise : Je d�veloppe du hard, je >fournit les specs et vous pouvez d�velopper le soft en open source... Sans >aller jusque l�, on peut r�ver qu'un fabricant donne l'acc�s � une partie de >son code/firmware. Mais bon, c'est quand m�me assez fantasmagorique :-) De l� � faire du open hard comme il en existe que de rares examples, il n'y a qu'un pas qui n'est pas si terrible que �a. Imagine tu plante sur le cross-bar un syst�me fifo pour les diff�rents bus que tu peut acc�der de fa�on multiplex� depuis les cartes (un connecteur 4x64 pin + signaux et peu cr�dible). Sur les cartes tu plante un convertisseur serie -> parall�le et un autre parall�le -> serie, le c�t� serie branch� sur un circuit d'interface physique au r�seau et de l'autre tu plante des m�moires fifo d'IDT (Integrated device technologie) et une m�moire � double acc�s pour le bus PCI. Tu chapaute ceci par un o� deux PLC de d'ALTERA ou de XILINK et un proceseur avec beaucoup de p�che (http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=01M0ylsDFTQ) et son entourage de ram statique, mem flash, quartz etc. Naturelement tout le firmare en flash. Avec �a t'est capable de traiter quasiement n'inporte quelle signaux et tu est extrainement souple au niveau du firmware. Le probl�me c'est le temps CPU disponible pour le traitement. Si tu utilise des convertisseur s-p de 64 bits tu doit quand m�me traiter un groupe de 64 bits tout les 16 ns , pas possible. Par contre une sorte de mini cross-bar entre les m�moires fifo du cross-bar inter cartes et celles faisant tampon avec l'ext�rieur et qu'un transfer sur le mini cross-bar puisse fonctionner en parall�le avec le traitement du processeur. Ceci t'offre le temps de remplissage des tampons pour trait� l'ent�te des paquets. C'est sur que l� il faut oublier le C et pass� � l'assembleur mais cela doit �tre possible si tu ne doit pas traiter de paquets trop petit. De plus le syst�me de clock recovery devrai �tre tactique. Pour avoir une id�e j'ai trouv� un sch�ma partielle � l'adresse http://www.centurysys.co.jp/english/oc12/S0641_02.pdf mais il doit en exister d'autre qui pourait donner de bonnes id�e. Bon la j'arr�te le d�lire. Remarque c'est le genre de projet qui me boterai pas mal hystoire de me changer du train-train cotidien. Persone ne veus faire une startup par hazard ? A+ Martial >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se d�sabonner aussi. ---------- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
