> Pavel Cahyna wrote:
> > kdyz sitovy kod z 4.4BSD neni IMHO prilis kvalitni (netvrdim ze v Linuxu
> > je...). Jednou vyhodou by mohla byt BSD license, ale to taky neni
> 
> Podle jakeho meritka 'neni kvalitni' ? Sitovy stack je i na 10GB/s

Ano, mel bych sve namitky konkretisovat. Ucinim tak. (Vit Herman necht
mi odpusti :-) )

1/ Chovani pri packetlossu - mel jsem firewall na kterem se ztracely
packety (kvuli tomu ze si sitovka spatne rozumela se switchem) a Linux
na jedne strane dokazal pres ten firewall na druhou stranu cpat data
daleko rychleji nez kdyz misto Linuxu bylo NetBSD. (V obou pripadech
byul na druhe strane Irix.) myslel jsem zpocatku ze je to tim ze linux
umi selective ACK, zatimco NetBSD ne, ale kdyz jsem SACK v Linuxu
vypnul, porad byl rychlejsi. Do TCP az tak nevidim, takze nejsem schopen
rict kde je problem.

2/ dalsi co me stve je to, ze kdyz udelam ifconfig <neco> up inet <adr>
atd. tak uz se toho rozhrani jen tak snadno nezbavim (kdyz treba v nem
neni kabel a chci pouzivat jine rozhrani). Muzu dat ifconfig <neco>
down, ale pakety pro adresy do te site jemu prislusejici se skrz nej
budou porad snazit prolezt a bude to hazet chyby, misto toho, aby pekne
sly druhym rozhranim. Ony tam totiz zustanou jakesi prime routy (tj. je
tam informace ze do te lokalni site se jde pres ono rozhrani) a ty
nezmizi kdyz dam ifconfig <neco> down. Musi se manualne odstranit
prikazem route.

3/ odpovedi na TCP spojeni ktere prijde do stroje se 2 sitovkama
sitovkou 1, mohou stroj opustit sitovkou 2, coz je proti specifikaci
TCP, ktera rika, ze maji jit stejnym rozhranim jako prichozi pakety
tehoz spojeni.

4/ rozsiritelnost (coz mi prijde jako nejzavaznejsi problem): 
mrknete se treba sem:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_ethersubr.c?rev=1.114&content-type=text/x-cvsweb-markup
konkretne na funkce ether_input() a ether_output()
Uvidite, ze ruzne protokoly jsou resene tak, ze tam jsou obrovske switch
... case "vyhybky" - pro kazdy protokol jedna vetev, ve ktere se provadi
protokolove specificke obcovani. Takze na pridani sitoveho protokolu za
behu v modulu muzete zapomenout - uzasne "modularni a rozsiritelny"
navrh. Proto nejde mit sitovy protokol jako LKM.

Chtel jsem kdysi implementovat sitovy protokol nad jinou linkovou
vrstvou (konkretne IPv6 nad Tokenringem) a zjistl jsem, ze bych musel do
spousty tokenring-specifickych funkci pridat obsluhu IPv6 a do IPv6
specifickych podporu tokenringu. Srovnejte si to s rozhranim pro
drivery, (kde kdyz chcete pridat podporu pro nejaky hardware nad jinou
sbernici tak nemusite menit ani ovladac toho hardwaru, ani ovladac te
sbernice, ale jen napisete nejaky spojovaci kod) a uvidite jak je sit ve
srovnani s abstrakcemi hardware v NetBSD (i ostatnich) zoufale
zanedbana.

5/ Nedavno byla na tech-net@ diskuse o cachovano rout a o tom jake to ma
nepriznive dusledky, pro detaily se podivejte tam (hledejte "Problems
with outgoing routing of UDP packets"). Mam dojem ze cachovani rout take
znesnadnuje implementaci sdileni vykonu mezi vice sitovkami (mozna je to
duvod proc tato vlastnost v NetBSD neni).

6/ ALTQ se mi nelibilo, jeho dokumentace neni nic moc. Sice
jsem traffic shaping v linuxu nepouzival (ostatne ani ALTQ), ale
dokumentace k linuxu na me udelala o dost lepsi dojem.

S polozkou 2/ ma tusim linux take problem, ale v ostatnich bodech je
lepsi.

> Struktury mbuf jsou sice mirne narocnejsi na pouziti CPU nez jine
> struktury, ale optimalizuji spotrebu pameti, coz kvuli TLB missum
> je naprosto primarni i v modernich architekturach s 'rychlou' RAM.

Struktury mbuf se mi taktez libi ...

> > Ani penize nejsou zarukou, ze se najde nekdo, kdo pozadovane vlastnosti
> > skutecne implementuje.  Uz nejakou dobu jsou vypsane odmeny
> > na funkcni 3D akceleraci v XFree86 na NetBSD a zatim se o ne pokud vim
> > nikdo neprihlasil. To neni jediny pripad. Zrejme je vyvojaru malo.
> 
> Problem je spis v tom, ze clovek, ktery vyhlasil bounty na 3D podporu
> pro NetBSD, se uz dale neozval. Zabyval jsem se timhle chvili a dotaz
> na toho cloveka je bez odpovedi nyni uz asi rok. 

Tak to jsem nevedel, omlouvam se za dezinformaci.

> Mimochodem, v -current s XFree 4.4 uz je zakladni podpora DRI
> hotova, je potreba jen odtestovat jednotlive DRI ovladace. Prozatim
> je otestovan jen DRI ovladac pro karty Matrox, IIRC.

Zajimave - mam ATI Rage 128, ke kteremu existuje DRI driver (v linuxu).
Kdyz budu mit konkretni instrukce co testovat, rad otestuji.

Zdravim	Pavel Cahyna