Re: [PATCH] update raw patch in POM

[Roberto Nibali <ratz@tac.ch>]

>>What neighbour needs to be resolved? The neighbour cache is full, only 4
>>addresses are involved, gc threshold is high, so no trashing. Or are we talking
>>different issues?
>  
> It was just a guess, I can't think of anywhere else where packets
> might have been queued for 30s, given that you have no packet
> sockets and probably don't have a long enough device queue that
> it would take 30s.

sem-arbeit:~# ip -s -s neigh show
172.23.2.30 dev eth0 lladdr 00:01:02:6c:23:f8 ref 3 used 0/0/69 nud reachable
172.23.2.31 dev eth0 lladdr 00:30:05:50:50:2b ref 1 used 3/0/224 nud reachable

That's all I have in the cache ;). The routing cache is more populated though:

sem-arbeit:~# ip -s -s route show cache
broadcast 255.255.255.255 from 172.23.10.16 dev lo  src 172.23.120.120
    cache <local,brd,src-direct>  users 1 age 136sec iif eth0
unreachable 172.27.1.10 from 172.27.232.50 dev lo  src 172.23.120.120
    cache  error 101 users 1 used 6 age 34sec iif eth0
local 172.23.120.120 from 172.23.2.31 dev lo  src 172.23.120.120
    cache <local,src-direct>  users 1 age 271sec iif eth0
broadcast 172.23.255.255 from 172.23.1.14 dev lo  src 172.23.120.120
    cache <local,brd,src-direct>  users 1 used 3 age 149sec iif eth0
unreachable 172.30.12.254 from 172.30.12.203 dev lo  src 172.23.120.120
    cache  error 101 users 1 used 29 age 11sec iif eth0
172.23.2.30 from 172.23.120.120 dev eth0
    cache  users 1 used 3 age 97sec mtu 1500 advmss 1460
local 172.23.120.120 from 172.23.134.111 dev lo  src 172.23.120.120
    cache <local,src-direct>  users 1 used 36 age 6sec iif eth0
172.23.2.30 from 172.23.120.120 tos lowdelay dev eth0
    cache  users 5 used 2 age 93sec mtu 1500 advmss 1460
unreachable 172.30.12.154 from 172.30.12.203 dev lo  src 172.23.120.120
    cache  error 101 users 1 used 5 age 182sec iif eth0
local 172.23.120.120 from 172.23.2.31 tos lowdelay dev lo  src 172.23.120.120
    cache <local,src-direct>  users 1 used 47504 age 0sec iif eth0
local 172.23.120.120 from 172.23.2.30 dev lo  src 172.23.120.120
    cache <local,src-direct>  users 1 used 37 age 93sec iif eth0
local 172.23.120.120 from 172.23.2.30 tos lowdelay dev lo  src 172.23.120.120
    cache <local,src-direct>  users 1 used 150 iif eth0
172.23.2.31 from 172.23.120.120 tos lowdelay dev eth0
    cache  users 5 used 3 age 225sec mtu 1500 advmss 1460
broadcast 255.255.255.255 from 172.23.10.19 dev lo  src 172.23.120.120
    cache <local,brd,src-direct>  users 1 used 1 age 100sec iif eth0
broadcast 172.23.255.255 from 172.23.232.138 dev lo  src 172.23.120.120
    cache <local,brd,src-direct>  users 1 used 1 age 32sec iif eth0
sem-arbeit:~#

>>>To confirm that
>>>theory you could play with the values in
>>>/proc/sys/net/ipv4/neigh/default and see if it changes anything.
>>
>>
>>I'll do that. How do you think I should instrument these values? And what does
>>the neighbour stuff have to do with conntrack timeouts?
> 
> 
> Try halving all values and see if it has any effects on the time
> it takes to unload the module.

Nope, I'll upload the new results shortly but the time is unchanged.

> I'm pretty sure the nf_reset + the wait-for-untracked-refs patches
> should take care of the problem, but to be sure it would be good
> to know where the delay came from.

Currently I do not run it with nf_reset patched kernels which is another really
strange thing. Some other timeout which is 30s? But I only see
udp_timeout_stream and icmp_timeout ...

Do you plan to submit the nf_reset and wait-for-untracked-refs patches for
mainline inclusion?

Best regards,
Robert Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------