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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list