helenos-nicf team mailing list archive

[Jirka Michalec <michy@xxxxxxxxxx>]

Ahoj,

posílám info, jak je na to v tuto chvíli driver rtl8139

- 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.
- 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)
- následující výsledky jsou na starých testech, změny v nictestu 
posledních dnů jsem ne
- filter test prochází na reálném HW, nikoliv však v qemu
-- důvodem je odlišnost chování qemu a reálného HW. Při změně registru 
obsahujícího, jaké packety má karta přijímat, reálný HW pokračuje v 
zapisování přijatých packetů tam, kde předtím skončil, qemu to bere 
pěkně od začátku. Implementaci jsem zaměřil na reálný hardware, což ale 
vede ke spožděné synchronizaci bufferu v qemu (dokud qemu nezjistí, že 
data v bufferu jsou zvláštní) - přesně toto řešení je použito i 
linuxovém driveru. Ještě mne napadá možnost udělat kompletní restart 
receiveru, čímž ale dojde k zahození všech packetů, které přišli po dobu 
změny módu.
- stress test výsledky (předpokládám, že co je zahozeno mezi driverem a 
nictestem, tj. hlášeno jako discarded, je zahozeno v ildummy, přesně 
jsem nezkoumal):
-- qemu momentálně:
---- s <1% ztrátou packetů ve fázi 1, ale cca 18% zahozeno v ildummy
---- 15 % ztráta v 2. fázi (tj. nepotvrzeno)
---- ztráty jsou způsobeny na obou stranách (receiver buffer overflow i 
tx_busy), nepotvrzení packetů téměř vše kvůli zahození v ildummy
-- HW (souhrn z testu všech pěti karet):
---- 0% packet loss v 1. fázy (konkrétně přesně 0 packetů na každé 
kartě), ale na HW, co mám, je cca 50% zahozeno v ildummy.
---- 40 - 42% packet lost, všechny ztráty jsou kvůli packetům zahozeným 
v ildummy
---- HW stihl přijmout a driver zpracovat vše odeslané (žádný packet 
nezahozen ani kvůli plnému bufferu přijímače)
- autonegotiation otestováno, funguje na všech kartách, musím ještě více 
prozkoumat detekci nastavení link partnera (i když nastavím
- set_operation_mode otestováno, funguje na všech kartách


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)
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)
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í.
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?

Michy