[P4] mai Ericssonos megbeszélés

Leskó Dániel ldani at elte.hu
Wed Oct 21 15:42:39 CEST 2015


Javaslat: Ezeket a heti összefoglalókat jó lenne feltenni a trac-ba, 
mert ott egy helyen megvan, könnyen visszakereshető, hivatkozható később is

Dani

2015.10.21. 15:40 keltezéssel, Tejfel Máté írta:
> Sziasztok!
>
>   Megpróbálom összegezni a mai információmorzsákat.
>
>  A Numa kapcsán kb. jó a megközelítésünk a táblákkal kapcsolatban, 
> hogy van egy központi inicializálás, ami a "numa node"-okon létrehozza 
> külön külön az üres táblákat. Egy ilyen node-hoz több szál (több 
> csomagfeldolgozó egység) tartozik, amik elég, ha a sajátjukat látják. 
> A controller felé hallgatózó control rész kapja meg a tábla sorok 
> feltöltési, módosítási, törlési, illetve a default action beállítási 
> igényeket és neki kell gondoskodnia arról, hogy ez minden táblán 
> megtörténjen.
>   Amire a táblákon kívül figyelni kell, azok számlálók (p4.counter), 
> ill p4.meter, de ez utóbbira azt mondták egyelőre hanyagoljuk. Ezeknél 
> vagy meg kell oldani az atomicitást, vagy ezt is core-onként külön 
> szedni és összegezni ha ki kell olvasni (ilyen ritkán van).
>   Aztán szintén megoldandó, de most nem olyan érdekes az ageing, azaz 
> hogy lejárhat a bejegyzések élettartama (ezt globálisan kell 
> figyelni). Ez esetleg megoldható úgy ha időnként a slowpath körülnéz, 
> hogy lejárt-e valamelyik bejegyzés és akkor töröl.
>   Ami már érdekesebb és gondolkodnivaló, hogy a tábláknál meg kell 
> oldani, hogy a lookup és a felülírás ne akadjon össze és mindezt 
> lockfree módon. Elhangzott pár ötlet, pl. hogy a teljes tábla 
> duplikálva van, az egyikből olvasunk, a másikba írogatunk és  néha 
> pointert cserélünk, vagy csak a tábla bizonyos részei vannak 
> duplikálva (plusz hash tábla ezekhez), illetve spideren van atomi írás 
> (néhány verzió megadott méretű adatokra).
>  Ehhez kapcsolódik, hogy az atomicitást is kezelni kell, azaz ha 
> lekértünk egy adatot és közben átírjuk a táblát, menet közben ne 
> változzon az adat. Tehát pl. ha nem a duplikált táblás megoldás van, 
> akkor egy lookupnál nem adhatunk a táblába mutató pointert (spidernél 
> most kimásolják az adatot és a másolatot adják tovább), de ha 
> duplikált táblánk van, akkor akár pointert is lehet adni (ha jól 
> értettem Molánál most ez van).
>   Illetve újfent előkerült, hogy memóriafoglalás maximum a 
> slowpath-nál lehet (pl. Mola emlegette, hogy a duplikált táblánál, 
> azon a részen, amit épp irkálunk akármit módosíthat a slow path, akár 
> még méreteket is). Azaz ha pl lookup-nál másolgatunk kell előre 
> lefoglalt hely, hova tesszük (spidernél ez van). Ez alapján szerintem 
> kellene a hardverfüggő részbe olyan függvény, amivel némi memóriát 
> kérhetünk és ez az előre lefoglalt részre tud pointert adni...
>
>  Ha kihagytam valamit, egészítsétek ki kérlek...
>
>         M.
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4



More information about the P4 mailing list