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

[Maxim Perevedentsev]

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 :)
>
>>> Is the "ip" command available on non-linux platforms? I know there 
>>> is *a lot* of netlink stuff in there). Aside from that, POSIX_SHELL 
>>> isn't even defined, so this code would fail to compile on non-Linux 
>>> platforms with IP_PATH defined (and it would fail to compile on 
>>> non-Linux with IP_PATH *not* defined, since addrs and count would 
>>> then need ATTRIBUTE_UNUSED). Anyway we try to avoid execing external 
>>> binaries unless absolutely necessary, so I think it's reasonable to 
>>> only have a stub function that says "not supported" in place of this 
>>> (very polite but non-working) replacement.
>> Ok. I wanted to work-around the case if we do not have libnl installed.
>
> There are other things that will fail if libnl isn't installed. Are 
> you actually building libvirt without libnl enabled and having any 
> amount of success? (since the only way we interact with netlink is via 
> libnl, anything that requires netlink will not work, e.g. macvtap 
> interfaces)
No, I don't. Thank you for explanation.

-- 
Your sincerely,
Maxim Perevedentsev