[P4] megbeszélés

[Tejfel Máté]

Sziasztok!

   Remélem mindenkinek sikerült kipihennie magát és mostantól újult 
erővel tudunk a feladatra koncentrálni :) Holnapra  jó lenne, ha 
mindenki tudna legalább mondani
egy konkrét listát, mi kellene még ahhoz, hogy rendesen fusson is a kód. 
Persze a legjobb az lenne, ha ténylegesen futna is végre...
   Ezen felül, akinél üres a fenti lista, gondolkodhatna a múltkor 
felmerült kérdéseken. (Bemásolom a múltkori levelem, ne kelljen 
keresgélni)...

            M.


"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..."