aboutgitcodebugslistschat
path: root/tcp_vu.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2024-11-25 08:50:39 +0100
committerStefano Brivio <sbrivio@redhat.com>2024-11-26 08:30:18 +0100
commitcda7f160f091515770a103765d50bac0f136faef (patch)
treedf67e780058543b75d7c2a0a27346b3035822466 /tcp_vu.c
parent2bf8ffcf078c5933e6a31dbffbfb4dc31bfd7bc5 (diff)
downloadpasst-cda7f160f091515770a103765d50bac0f136faef.tar
passt-cda7f160f091515770a103765d50bac0f136faef.tar.gz
passt-cda7f160f091515770a103765d50bac0f136faef.tar.bz2
passt-cda7f160f091515770a103765d50bac0f136faef.tar.lz
passt-cda7f160f091515770a103765d50bac0f136faef.tar.xz
passt-cda7f160f091515770a103765d50bac0f136faef.tar.zst
passt-cda7f160f091515770a103765d50bac0f136faef.zip
ndp: Don't send first periodic router advertisement right after guest connects
This is very visible with muvm, but it also happens with QEMU: we're sending the first unsolicited router advertisement milliseconds after the guest connects. That's usually pointless because, when the hypervisor connects, the guest is typically not ready yet to process anything of that sort: it's still booting. And if we happen to send it late enough (still milliseconds), with muvm, while the message is discarded, it sometimes (slightly) delays the response to the first solicited router advertisement, which is the one we need to have coming fast. Skip sending the unsolicited advertisement on the first timer run, just calculate the next delay. Keep it simple by observing that we're probably not trying to reach the 1970s with IPv6. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'tcp_vu.c')
0 files changed, 0 insertions, 0 deletions