Besoin

Possibilité de gérer plusieurs VCI
Une utilisation possible est d'avoir plusieurs flux ayant un critère discriminant (le VCI) pour y appliquer un traitement particulier (de la QOS par exemple)
Voir aussi MultiLink

Implémentation(s) possible(s)

• actuel : rejet des VCI non définis
• associer une autre interface virtuelle à chaque VCI : le moins intrusif et le plus facile (?) à fournir à un programme linux
• garder le VCI : difficilement envisageable, cela correspondrait à laisser passer un flux ATM (je dis une connerie là... ?)

Impacts

• définir les VCI possibles dans eagle-usb.conf
• monter interfaces supplémentaires
• identifier l'interface (au sens API) de lecture par des programmes

Questions annexes

• pas d'impact sur chargement du firmware
• pas d'impact sur la synchro qui ne cherche qu'à repérer un flux de cellules

copier/coller à organiser

De: Benoît Audouard
A: sl33p3r
Date: Thu, 11 Mar 2004 23:25:43 GMT
Sujet: plusieurs VCI
si on pouvait avoir plusieurs VCI actifs
en même temps ? ou en changer facilement ?
- avec plusieurs modems je vois à peu près comment faire (quoique...) le
driver doit être chargé plusieurs fois, ça me semble un peu foireux
- avec un seul modem, tout arrive sur la même interface ? avec le même
encodage ?
- ya un impact sur le chargement du firmware / code DSP ou ce n'est que dans
le paquet reçu qu'il faudrait l'orienter correctement ?
- si ce n'est que dans le paquet, je pense que ça a un impact sur la synchro
quand même ? ou alors la synchro ne dépend que du protocole (encapsulation) ?
ou que du VPI ? (pas du VCI tout de même)
- c'est dépendant du firmware ? t'as pu regarder les option de l'USR
robotics ? (ou tu connais quelqu'un qui en a un avec qui on pourrait prendre
contact ?)
T'as des liens vers des specs intéressantes sur le sujet ? ou des how-to...
(je préfère apprendre à pêcher que tu me donnes un poisson ;-) )
ça se monterait sous linux un dslam ou faut un équipement spécifique ? genre
un fil de cuivre ça suffit pas ?
J'en ai plein des questions à la con comme ça, si tu connais un gars intéressé
je veux bien monter une ML dédiée sur gna.org

De: Frederick Ros <sl33p3r
A: Benoît Audouard <baud
Date: Fri, 12 Mar 2004 09:31:24 +0100
> - avec plusieurs modems je vois à peu près comment faire (quoique...) le
> driver doit être chargé plusieurs fois, ça me semble un peu foireux
> - avec un seul modem, tout arrive sur la même interface ? avec le même
> encodage ?

Ouaip .. en gros dans les paquets qui arrivent tu as le VPI/VCI de destiantion :
si c'est le tien tu process sinon tu discardes... Enfin je te dis ca de tete
faudrait que je re-verifie mais j'en suis sur a 90%

> - ya un impact sur le chargement du firmware / code DSP ou ce n'est que dans
> le paquet reçu qu'il faudrait l'orienter correctement ?

Pas d'impact sur le chargement DSP / firmware .. A la limite dans celui des
options car il faudrait forunir plusieurs VPI/VCI.

> - si ce n'est que dans le paquet, je pense que ça a un impact sur la synchro
> quand même ? ou alors la synchro ne dépend que du protocole (encapsulation) ?

Elle ne depend IMHO ni de l'encapsulation ni du VPI/VCI ... En fait la synchro
c'est juste de se synchronier avec un flot ininterrompu de donnees, pour pouvoir
determiner ou est le debut d'une cellule par exemple.

> - c'est dépendant du firmware ? t'as pu regarder les option de l'USR
> robotics ? (ou tu connais quelqu'un qui en a un avec qui on pourrait prendre
> contact ?)
Non dependadnt du firmware ( enfin je pense je l'ai pas desassemble).
Je connais personne avec un USR, et j'a ias eu le temps .. Tu veux dire le truc
dont on a parler aevc Gesp ?

> T'as des liens vers des specs intéressantes sur le sujet ? ou des how-to...
> (je préfère apprendre à pêcher que tu me donnes un poisson ;-) )

Nope .. J'ai fait qq recherches sur le Net, sinon c'est en lisant les sources ..
mais bon la partie que l'on voit d'ATM est _tres_ basique ..

> ça se monterait sous linux un dslam ou faut un équipement spécifique ? genre
> un fil de cuivre ça suffit pas ?

J'sais po . Faudrait que je reprenne des cours de telecom .. J'etais plutot
protocoles de signalisation moi ...

> yaurait plusieurs interfaces virtuelles ? une par driver ?

A voir ... en fait apres y'a plusieurs moyen de faire : changement de
l'encapsulation, dedie une interface / VPI/VCI ..etc...

> et plutôt que discarder, faudrait laisser passer ou envoyer sur une autre
> interface ? le VCI est dispo dans le paquet pour le programme qui écoute
> l'interface ethX ? comment tu récupèrerais le flux si tu avais à le faire ?
> (moi j'ai l'impression que ce serait sur une interface... mais ya peut-être
> d'autres possibilités ?) Faudrait lui redemander au gars où il en est ;-)

Je pense aussi que le plus simple serait d'avoir plusieurs interface .. Ca evite
de changer l'encapsulation pour un truc "proprio" , et ca simplefie la gestion
de la part de l'utilisateur ..
On peu aussi penser que ca passe un peu mieux a l'echelle ( si la queue d'un
interface se remplit trop ca bloque pas tout le monde).

> les options ce n'est que pour le module ? elles ne sont pas envoyées au modem
> en fait ? (enfin pas VPI/VCI en tout cas ?)

Nope.. pas envoye au modem ( encore une fois, de memoire) ...


> oui ça et aussi le firmware avec les options supplémentaires que j'ai trouvé
> dans le driver que USR fournit (voir en bas de http://eagle-
> usb.ath.cx/eagledev/wakka.php?wiki=ConfigFiles ) faudrait les contacter...
> genre pour leur proposer un driver qui marche ;-)

Faut que je regarde comment re-incorporer tout ca ...


De: Benoît Audouard <baud
A: Frederick Ros <sl33p3r
Date: Fri, 12 Mar 2004 10:36:37 GMT
Sujet: Re: plusieurs VCI

> Quoting Benoît Audouard <baud
> > yaurait plusieurs interfaces virtuelles ? une par driver ?
> A voir ... en fait apres y'a plusieurs moyen de faire : changement de
> l'encapsulation, dedie une interface / VPI/VCI ..etc...
bon interface virtuelle donc (cf. ci-dessous)
> > et plutôt que discarder, faudrait laisser passer ou envoyer sur une autre
> > interface ? le VCI est dispo dans le paquet pour le programme qui écoute
> > l'interface ethX ? comment tu récupèrerais le flux si tu avais à le faire ?
> > (moi j'ai l'impression que ce serait sur une interface... mais ya peut-être
> > d'autres possibilités ?) Faudrait lui redemander au gars où il en est ;-)
> Je pense aussi que le plus simple serait d'avoir plusieurs interface .. Ca
evite
> de changer l'encapsulation pour un truc "proprio" , et ca simplifie la gestion
> de la part de l'utilisateur ..
> On peut aussi penser que ca passe un peu mieux a l'echelle ( si la queue d'un
> interface se remplit trop ca bloque pas tout le monde).
bon va falloir que je copie/colle sur l'eagledev...
> > les options ce n'est que pour le module ? elles ne sont pas envoyées au
modem
> > en fait ? (enfin pas VPI/VCI en tout cas ?)
> Nope.. pas envoye au modem ( encore une fois, de memoire) ...
Je suis reloud mais ce serait bien de documenter les interfaces... le reverse
engineering est bien autorisé sur du GPL ? et comme on n'a pas de doc' ?!
> > oui ça et aussi le firmware avec les options supplémentaires que j'ai trouvé
> > dans le driver que USR fournit (voir en bas de http://eagle-
> > usb.ath.cx/eagledev/wakka.php?wiki=ConfigFiles ) faudrait les contacter...
> > genre pour leur proposer un driver qui marche ;-)
> Faut que je regarde comment re-incorporer tout ca ...
faudrait aussi trouver un testeur tout de même... nous on ne peut que faire la
non régression (peut-être revoir avec Gesp)
> > ah bin t'en as fait plus que moi !
> > le cours de telecom était le lundi matin à 8h en 3èmeA, ça aide pas :-))
> > et puis c'est pas l'école qui m'a vraiment appris l'informatique...

---