"Pri klonovani se vytvori nekolik struktur struct sk_buff, ktere ukazuji na tataz data."
No nevim, neni to trochu nebezpecny? Co kdyz je jedna kopie uvolni, pak by vsechny ostatni padly na pristupu. Asi tam melo byt ze obsahuji tataz data, ne ze ukazuji na stejna data.
Hmmm..... a co nasledujuca veta???
"Nejdůležitější je počítadlo, kolik sk_buf se na tuto oblast odkazuje. Při smazání posledního klonu toto počítadlo dosáhne nuly a datová oblast je uvolněna."
ak som to pochopil tak uvolnenim sa rozumie znizenie pocitadla odkazov o 1 a ak je toto pocitadlo nulove potom dojde k uvolneniu
Neviem ci bude este nejake pokracovanie o sietach, ale velmi by ma zaujimalo ako je to s alokovanim pamate pre tie sietove buffery, kedze nedavno sa mi stalo na fBSD 4.8, ze sa spotrebovala vsetka vyhradena pamat pre mbuf.
Na stroji je sice 512MB RAM, ale na mbuf si jadro alokuje len nejaku cast (tusim je to 1/16 fyzickej pamati), co v mojom pripade bolo 32MB a to nestacilo pre routovacie tabulky, ktore potrebovali okolo 36MB, kedze na danom boxe bezim Zebru a BGP.
Rad by som vedel nejake hodnoty napr. kolko sa alokuje pre jednu routu a tak ako je to napr. vycislene pri CISCOach.
Pokial sa pamatam, fBSDcku mozes v configu kernelu povedat pocet mbufs a mbuf clusters, ktore ma alokovat. Ak mu nepovies, povie si samo pri boote v zavislosti od mnozstva pamate.
Skus tam napisat nieco ako
options NMBUFS=vela
options NMBCLUSTERS=vela
A samozrejme netstat -m povie, kolko ich mas, kolko ich mas pouzitych a kolko najviac si ich mal pouzitych.
Ve zdrojacich via-rhine a 8139too se bohuzel vyskytuji taky. Vzhledem k tomu, ze kvuli zarovnani se musi data tak jako tak prekopirovat, delaji ovladace gather/scatter jaksi softwarove. Nicmene i u prachobycejne integrovane via-rhine II je zerocopy poznat - u proftpd skompilovaneho s --enable-sendfile mi klesne zatez CPU na cca dve tretiny az polovinu oproti stavu bez zerocopy.
