[P4] big endian, little endian

[Tejfel Máté]

Sziasztok!

   A jó hír, hogy HDaninál már kb megy a full-os L3 példa, viszont ennek 
kapcsán elkezdtünk beszélgetni és gondolkodni a big-little endian-os 
váltásokon. Most ezt nagyon kevés helyen csináljuk, ott sem, ahol 
kellene. Át kellene gondolni, hogy hova rakjunk. Alapvetően a táblákban 
történő eltároláson gondolkodunk, a csomag fieldjeit, nem akarjuk 
bántani, ott feltételezzük, hogy big endian-ban van (ugye ez a network 
order...
  Ha Danival jól gondoljuk a controller-től jövő minden üzenetnél 
feltételezhető, hogy big endian-ban vannak az adatok. (Ez igaz Sanyi? 
Vagy elvileg akár "rá lehetne venni" a controller-t, hogy little 
endian-ban küldjön?) Most ezeket mindig így tároljuk el a táblákba, akár 
kulcsról, akár értékről (pl. függvény paraméterről van szó).
   Ez a kulcs esetén lpm-nél nem jó (kipróbáltuk), úgyhogy ott Dani első 
körben átírja, hogy a táblába kerülés előtt megforgassuk a kapott 
adatot, illetve lekérdezéskor is megforgassuk, ami alapján keresünk 
(persze ez sem teljesen triviális, mondjuk, ha több field-ből áll elő az 
lpm...). Kérdés, hogy ezt hosszabb távon nem lehet-e hatékonyabban (pl. 
saját/más lpm keresés).
   Amire nem tudjuk az igazán jó választ, hogy mi legyen az értékekkel, 
azaz pl. az action függvény paraméterekkel. Pl. modify_field esetén, ha 
a csomag mezőit piszkáljuk (egyelőre ez tűnik a leggyakoribb esetnek), 
jó, hogy big endian-ban van, ha egy metadata-t piszkálunk, inkább little 
endian kellene, ha pl. add_to_field paraméterben jelenik meg, akkor 
megint csak inkább little endian lenne jó, ha pedig feltételezzük, hogy 
az action függvényen belül módosulhat a paraméter mielőtt egy primitív 
függvényben felhasználjuk, akkor ismét a little endian a jó...
Szóval megoldásként, ami eddig eszünkbe jutott:
  -- marad minden big endian és ahol kell (pl. fenti add_to_field, 
modify_field esetek) figyelünk erre (egyelőre ezt próbálja Dani 
megvalósítani)
      -- itt talán kevesebb forgatás kell (egyelőre azt feltételezzük, 
az a jellemzőbb eset, hogy a big endian-os alak a jó, ezt persze jó 
lenne végiggondolni), viszont
          ennél ha valaki egyéni módon próbál használni egy fv 
paramétert, fura dolgok sülhetnek ki...

-- csinálunk valami egyszerűbb statikus elemzést fordításkor, hogy az 
adatot hol fogjuk használni és ez alapján eldöntjük, milyen módban tároljuk
     -- itt még kevesebb forgatás kell, (esetleg eladható 
optimalizálásnak :) ), viszont inkonzisztens lesz a tárolás és utólag 
nem biztos, hogy egyszerű lesz kitalálni,
         hogyan is tároltuk az adatot, emiatt fontos kérdés, hogy 
elképzelhető-e olyan (értelmes) eset, hogy nem eldönthető, miben lenne 
jó tárolni (több eltérő dologra is
         használunk egy paramétert egy függvényben)...

-- minden adatot (a kulcsokat azért nem) még táblába írás előtt átrakunk 
little endian-ba és ahol kell (pl. sima modify_field) konvertálunk
     - valószínű itt kell a legtöbb forgatás (ez lenne a leglassabb), 
viszont elméleti oldalról ez tűnik a leghelyesebbnek és persze ez lenne a
       legbiztonságosabb (minden fv. paraméter egyértelműen little 
endian, mindentől függetlenül, azaz bármire használják a függvényen 
belül, nem lesz váratlan az
       eredmény)

  Egyéb ötlet? :) Illetve, ha valamit nem gondoltunk át (jól) a 
fentieknél, szóljatok és kérlek, ti is gondolkodjatok rajta, mi lenne a 
legjobb verzió...

    Köszi!

         M.