helenos-nicf team mailing list archive

[Radim Vansa <radim.vansa@xxxxxxxxx>]

Ahoj

> - použití DMA paměti pro buffery (a tudíž zamezní kopírování) do rtl 
karty implementovat nebudu. Důvodem je to, že RTL umí pracovat pouze s 
pamětí zarovnanou na 4B, při testování (ať už ping či nictest) karta 
žádný vhodně zarovnaný packet nedostala, byl by to (pokud se nezavede 
nějaká možnost vynucení zarovnání dat packetu) jen zbytečný kód, 
kopírovalo by se tak jako tak.

No přijde mi to jako škoda (nastavit konstanty pro prefix vhodněji, aby 
to pro ethernetovou hlavičku, která je typicky těch 14 bytů dlouhá (což 
právě způsobí to nezarovnání)), ale budiž.

> - přepisuji kód přijímání packetů (stress test pro současně 
> commitnutou neměl zrovna nejlepší výsledky), následující výsledky jsou 
> už pro prvotní verzi nového postupu)

Nový protokol testů je jenom pro obecné propojení se mastera a slave, 
samotný stress test jsem skoro neupravoval.

> - filter test prochází na reálném HW, nikoliv však v qemu

HW je hlavní, že něco nefunguje v qemu asi není takový problém. Pokud je 
jednoduché aspoň v compile-time přestavit verzi funkční na qemu/na HW, 
bylo by to ještě lepší.
> A několik věcí, co potřebují alespoň trochu ujasnit:
> 1) Děcký mluvil o tom vytvoření interface pro DMA řadiče podobně jako 
> pro síťovky - jak toto rozhraní má vypadat? IMO něco jako:
> - dmadev_copy(source_phys_addr, dest_phys_addr, &transfer_id);
> - dmadev_transfer_state(transfer_id);
> Čili dát controlleru vědět co a kam se má přenést a moci se zeptat, 
> jestli už to je hotové. Případně se ještě moci se otázat na celkový 
> stav DMA controlleru + zapnout/vypnout (dma_dev_state(&enabled, 
> &transfer_in_progress, &transfer_waiting_count), 
> dmadev_enable(true/false)).
> Má to někdo přidělené? (pokud ano a je-li rozhraní už rozmyšleno, pak 
> toto můžete ignorovat)

O tomhle jsme se bavili s Honzou, říkal, že se o to pokusí, pokud to 
bude stíhat. Není to top priority, když to ani nevyužijeme. Tím 
interfacem DMA řadiče bylo asi myšleno hlavně to, že ta práce s fyzickou 
pamětí, kterou máme, nemá být nějak omezena na ty síťovky, což není.

> 2) pořád mám pocit, že by write_packet, resp. driver, měl být schopen 
> oznámit "nemohu odeslat packet". Sice je ethernet nespolehlivé médium, 
> ale i tak mi přijde, že brzká detekce chyby pomůže zlepšit síťový 
> provoz, např. že by TCP vrstva by mohla zjistit problém a místo 
> pokračování v posílání sekvence packetu by rovnou odeslala lokálně 
> ztracený packet znovu. Pravdou je, že je zatím v ETH vrstvě návratová 
> hodnota nic_send_message ignorována, ale to nemusí být navždy - a 
> takováto případná změna se bez podpory v nicf neobejde. (mimochodem 
> toto ovlivňuje i výsledky stress testu - pokud je nictest rychlejší, 
> než driver zvládá, zahodí se packety už na straně mastera (k čemuž u 
> rtl na masterovi dochází), pro přesnější přehled je tudíž nutné 
> kouknout i na statistiky karty mastera)

Jako vyloženě proti tomu nejsem, ale já bych na to kašlal. Co udělá ta 
vrstva, bude se busy stylem snažit ten packet odeslat, nebo má tam 
usleepovat? O nějakých návratových hodnotách write_packet jsme se už 
předtím bavili. Co na to vy ostatní?

> 3) poll() callback má vyvolat co? Jen přijímání nebo celou obsluhu 
> přerušení? V linuxu je to (alespoň dle rtl driveru) jen přijímání, mně 
> dává velký smysl řešit tak i zbytek přerušení (např. k umožnění 
> použití karet i tehdy, nelze-li z nějakého důvodu používat přerušení 
> hardwarová). Pro srování - v Linuxu jsou dva callbacky: poll() pro 
> přijetí packetů, poll_controller pro simulaci celého přerušení.

Vzhledem k tomu, že jiný poll nemáme, tak určitě komplet přerušení. Je 
pravda, že by nemuselo být špatné mít tam argument, který říká "zajímá 
mě jenom přijímání" (ale může stále udělat i více).

> 4) Jména souborů s nastavením PCI karet - v současnosti jsou nazvána 
> podle karty, nicméně rozhodující je údaj HWPATH. Tím například dochází 
> ke konfliktu nastavení rtl8139 a e1000 - obě jsou v qemu na 
> '/hw/pci0/00:03.0/port0' - zřejmě se berou dle abecedního pořadí, čili 
> e1000 má přednost. Nebylo by lepší pojmenovat konfigurační soubory i 
> jména karet např. pci03/eth_03/...? Čili opravdu tam zakomponovat to, 
> z čeho se nastavení bere?

Já jsem měl vždycky za to, že to 00:03.0 je určeno jako pořadí PCI 
zařízení - pokud jsem v qemu zapnuty najednou obě síťovky, tak bude 
alespoň jedna identifikovány jinak. Ten konflikt bys odstranil leda tím, 
že bys k té identifikaci připojil i typ síťové karty (který by si tam 
připojil ovladač), ale to se mi moc nelíbí. Ty soubory má vytvářet 
administrátor, ten si jejich přítomnost vybere podle konfigurace HW.
Ohledně toho, že pro NAME používáme jméno toho hardware - to možná 
opravdu není nejvhodnější, klidně to na eth0 může poměnit.

Radim