Re: [PATCH] update raw patch in POM

[Patrick McHardy <kaber@trash.net>]

Roberto Nibali wrote:

>>>Jun 22 15:12:48 s_int@sem-arbeit untracked_use_cnt: 2, conntrack_cnt: 0
>>>Jun 22 15:12:53 s_int@sem-arbeit ip_conntrack version 2.1 (8192
>>
>>buckets, 65536 max) - 324 bytes per conntrack
>>
>>This actually looks good, no leak, no crash. Not sure where the 30
>>second delay comes from, my guess is that packets are queued while
>>the neighbour is resolved, although its pretty long.
> 
> 
> 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.

>>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.

>>How long did you wait that time?
> 
> 
> Shoot, I really don't remember, sorry. I thought it was more than 30 seconds but
> I really can't tell.
> 
> I'll run some more tests and see if this 30 seconds delay can be reduced.

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.

Regards
Patrick