dropwatch - pouzitelnost

[Dalibor Toman]

DD,

On 9/15/2015 8:30 AM, Petr Barta wrote:
> Nejsem na dropwatch expert, ale pokud vim, potrebuje trochu zkusenosti 
> a cteni kodu na to, aby se dal pouzit nejak rozumne (zkusenost bych 
> snad mel, ale to cteni kodu mi dela problem ;-) ). Docela pekny zaklad 
> je treba na https://access.redhat.com/solutions/206223
>
to si bohuzel neprectu , nemam zadne subscription od RH.

Mozna mi unika princip sledovani dropu. Pokud vim tak dropwatch vyuziva 
tracepointy v kernelu, konkretne monitoruje volani  funkce 
kfree_skb()<http://lxr.free-electrons.com/ident?v=3.6;i=kfree_skb>. Neni 
mi ale jasne jak na zaklade pocitani pouziti te funkce dojde ke dropum. 
Tahle funkce se prece musi volat i pri beznem zaniku skb bufferu po 
zpracovani (uspesnem) packetu. Ale asi plati nejaka umluva, ze na 
mistech kde se dropuje se vola kfree_skb(), ktera zavola prislusny 
tracepoint a na miste kde skb ma byt uvolneno po doruceni packetu se 
vola __kfree_skb() nebo neco podobneho, co zavola jiny tracepoint 
(trace_consume_skb(skb)). Viz 
http://www.spinics.net/lists/netdev/msg210294.html.

Jenze mi to nejak zatim nesedi s tim, co mi reportuje 
dropwatch/systemtap. Mozna pouzite jadro nema v poradku prislusne 
tracepointy.

Ted momentalne se snazim prijit na to, proc pribyvaji tx_droppped 
packety na VLAN interface jednoho routeru (ScientificLinux 6.7). 
Countery se chovaji zajimave - vetsinou par dropu za 5 minut ale obcas 
50/sec v souvislem useku desitek minut (bez souvislosti s tokem dat). 
Pravdepodobne to nema na funkci vliv (mozna jsou to nejake packety, 
ktere z principu VLAN rozhrani zahazuje a mozna vznikaji lokalne), 
zadnou ztratovost forwardovanych packetu jsem primo kvuli tomu zatim 
nepozoroval, ale chtel bych mit jistotu. Ta vlanka je nad bondovanym 
rozhranim ze 2 ethernetu ...


Diky

-- 
Dalibor Toman