helenos-nicf team mailing list archive

[Jirka Michalec <michy@xxxxxxxxxx>]

Ahoj,

věnuji se testování a opravování chyb. Při testování jsem rozšířil 
nicconf a nictest o podporu polling mode a opravil některé s tím 
související deadlocky a pád ildummy. Přidal jsem několik záznamů do 
mantisu (některé jsou co se řešení týče triviální, jen bych k nim rád 
měl i jiný názor na to, které z řešení je lepší pro případ, že mi něco 
uniklo).
Konečně se mi též podařilo nabootovat na reálném HW a testovat tam.
Z celkem pěti karet, které mám k dispozici, byly 4 detekovány a 
přiřazeny ke správnému driveru, jedna nikoliv (zřejmě používá jiné 
vendor ID a device ID, bohužel toto už ve výpisu do kernel console není, 
ale čekám, že až tyto informace do výpisu přidám, zbývající kartu rychle 
zprovozním).
Všechny detekované karty vykazují naprosto stejné chování (alespoň v 
rámci testovaných funkcionalit): po startu funguje přijímání i odesílání 
packetů (broadcast i unicast), nefunguje změna MAC adresy (přijímají 
stále na původní) a po změně bcast modu přestane přijímat úplně (změny 
ostatních jsem zatím nezkoušel), v QEMU  vše zmíněné funguje správně.
V QEMU jsem stále nedokázal zprovoznit periodický polling, on_demand 
funguje správně, stejně jako přijímání pomocí přerušení.

Dále budu pracovat na odstraňování chyb a uváděním všech karet do 
správně fungujícího stavu.

> A mám taky jednu otázku ohledně designu: ve funkcích ohledně alokování 
> packetů je race, který způsobuje, že občas se prostě nepodaří 
> naalokovat packet, ačkoliv možné to je (ještě nedošla paměť). Zamykat 
> by to ani nešlo a v podstatě to není problém - otázkou ale je, jestli 
> to má řešit knihovna (cyklit, dokud se nepodaří naalokovat), uživatel 
> (dostane chybu, že se nepodařilo alokovat, ať si dělá co chce) nebo 
> jestli to zkusit třeba 8x v cyklu naalokovat a když se to nepodaří ani 
> jednou, tak teprve tehdy vrátit chybu. Já bych byl pro to poslední 
> řešení, co vy na to?

Můžeš se trochu více rozepsat o tom, kde ta race je, příp. ve kterých 
funkcích se projevuje (jde-li o race na straně packet serveru či 
driveru)? Jedna race je v dma_allocate_anonymous  (při volání ze dvou 
vláken mohou obě najít stejnou volnou virtuální adresu, avšak vytvoření 
mapování se povede jen jednomu) - o tom jsem už mluvil na jedné ze 
schůzek, když jsme DMA řešili, a shodli jsme se, že finální řešení bude 
v případě neúspěchu několikrát zopakovat postup a vrátit neúspěch až 
poté (ale zdá se mi, že to zapadlo). V tomto případě by šlo i zamykat, 
ale jen globálním zámkem v celé DMA  knihovně (což ale nepomůže při 
současném volání jiných funkcí alokujících paměť mimo DMA knihovnu), 
rozumnější mi opravdu přijde zkusit několik pokusů. Na druhou stranu je 
otázkou, zda-li má opravdu tato funkce myslet na možnost více vláken 
volajícího nebo si to má volající zajistit sám.
Co se alokace packetu týče - IMO typycká aplikace (driver) poběží v 
několika vláknech a tudíž by tyto funkce měly s více vlákny počítat a 
snažit se to rozumně řešit. Poslední zmiňované řešení se mi též líbí 
nejvíce, v takovém případě by bylo dobré odlišit návratový kód "opravdu 
není paměť" od "nastal race, příště se to možná podaří" - otázkou ale 
je, jestli je toto schopen framework rozlišit, např. dma_allocate vrací 
v případě neúspěchu ENOMEM nehledě na důvod.

Michy