Re: [PATCHv3 1/2] network: added waiting for DAD to finish for bridge address.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/19/2015 08:36 AM, Maxim Perevedentsev wrote:


On 10/16/2015 08:13 PM, Laine Stump wrote:
On 10/16/2015 12:51 PM, Maxim Perevedentsev wrote:
On 10/15/2015 09:03 PM, Laine Stump wrote:
This loop *really* bothers me, because there is no failsafe to terminate it if we never get positive notification that DAD has completed. This would lock up the network driver startup, which would lock up libvirtd startup. I think we need to decide on what is the maximum time this could possibly take to complete (maybe it is somehow based on the number of interfaces? or maybe it doesn't matter...) and timeout from the loop after the appropriate iterations.
I did not hear about general timeout for this operation. Maybe 5 min, for example?

5 minutes is a very long time when everything else is being held up. If the wait for each network is much beyond a couple seconds, we'll need to think about spawning off a thread to wait for DAD.

(if you're curious where the single-threadedness is, look at virStateInitialize() - it calls the stateAutoStart() function for each subsystem driver in sequence, and within the stateAutoStart() for the network driver, each network with autostart set is called in sequence).
I looked at kernel sources. It looks like DAD time is configurable:
rand() % net.ipv6.conf.default.router_solicitation_delay [1s] + net.ipv6.conf.default.dad_transmits [1] * net.ipv6.neigh.default.retrans_time_ms [1000ms]

By default on my machine, it gives 0s + 1 * 1000ms = 1s maximum.
Kernel keeps track of DAD success (on timeout) / fail. We could take these variables from sysctl, but this is cumbersome. I suggest taking 5s as maximum timeout and hope this is not too long.

Yes, I *really* do not want to write this thread-related stuff :)

I agree. I think it would be okay to put a 5s timeout on the loop. We should probably have a VIR_DEBUG before we start waiting for DAD, and another when we're finished, so that someone experiencing long delays in startup will be able to determine the reason.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]