| Thread Previous • Date Previous • Date Next • Thread Next |
Máš pravdu, špatně jsem vyjádřil, co je tou prioritou. Tou je mít maximálně rychlé předávání packetů - a možná beru mylný předpoklad (pocházející z monolitických kernelů), že kopírovat tu paměť je příliš drahá operace. Pro správné uvážení by to chtělo mít nějaké odhady performance IPC. Ovšem nějaké bottleneckovitosti packet serveru/DMA bych se zase tak nebál, pokud by se ukázalo, že to něco brzdí, tak se alokace a uvolňování packetu v nějakých cache-frontách dají implementovat lock-free.Problemem s odhadem performance IPC je velka zavislost IPC na momentalnim vytizeni systemu - IPC trva od suspendovani vlakna volajiciho az do okamziku probuzeni serveru. Coz muze byt rychle (napr. jsou v planovaci hned po sobe ci je system malo vytizeny) i pomale (vytizeny system), zavisi to na mnozstvi komunikujicich se serverem,...
Tohle je asi otázka na Honzu, jestli v tom není nějaký zádrhel. Tedy pro přijímané packety by driver požadoval od DMA nějakou paměť a pro odesílané by si (v případě potřeby) zjistil její adresu. Nicméně aplikační úroveň (resp. knihovna) by o tom, že tato paměť je nějak zvláštní a musí se uvolňovat skrze DMA stejně musela vědět, ne? Nebo jak zjistí DMA, že ji může znovu přidělit?V podstate to muze resit podobne jako u odesilani: naalokuje si normalni packet (bez DMA), pomoci obdoby dma_map_page se zpristupni jeho data pro dma prenos, a az karta prijme packet do teto pameti, udela z ni pomoci dma_unmap_page pamet normalni. Cili by v podstate v DMA existovaly dva druhy pameti: stala (stale buffery, alokace na dlouhou dobu) ziskana pres dma_allocate, a docasna (male veci na kratkou dobu) mapovana pres dma_map_page. Coz koresponduje s tim, ze packet je nutne zpristupnit pro DMA prenos jen na kratkou dobu pri prijimani (coz bude ve srovnani s celkovym zivotem packetu zpravidla zanedbatelny cas). Nicmene, pokud budou vsechny DMA pozadavky chodit pres IPC na server, bude zde ono neprijemne IPC volani, ktere vse zpomali (coz je o to neprijemnejsi, ze bude v obsluze preruseni - i kdyz v dany moment staci, kdyz bude zamcena jen cast driveru nutna k prijimani packetu). Co se rychlosti tyce, bylo by vyhodnejsiimplementovat tyto dma funkce jen jako syscally - typicky se budou volat casto, narozdil od dma_allocate, ktera se bude volat typicky jen pri startu aplikace (resp. v add_device).
Poradi soucasne komunikace je definovane tim, ze nekdo drzi zamek na phony. Chapu to dobre tak, ze async session tedy v podstate zamkne dany phone na dobu trvani session? Nebo toho muze zamknout phonu vice (napr. kdyz se musi zaroven komunikovat s vice servery)?Nemuze u async sessions dochazet k problemum s prohazenim poradi akci ruznych vlaken stejneho device? Resp. v NICF me nenapada me nic, kde by predbehnuti zpravy jineho vlakna mohlo vadit, ale spis jestli jsem neco v tomto smeru neprehledl... Jinak to zni jako dobre reseni - v driverech bude o nebezpeci deadlocku mene.Pořadí "současné" komunikace je stejně nedefinované - sessions zajistí to, že se komplikovanější komunikace sestávající se z více IPC zpráv nebudou prolínat.
Michy
| Thread Previous • Date Previous • Date Next • Thread Next |
