From: Pavel Fedin <p.fedin@samsung.com>
To: 'Yuanhan Liu' <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org, 'Victor Kaplansky' <victork@redhat.com>
Subject: Re: [PATCH 0/4 for 2.3] vhost-user live migration support
Date: Tue, 15 Dec 2015 17:58:28 +0300 [thread overview]
Message-ID: <00f101d13749$0eb97330$2c2c5990$@samsung.com> (raw)
In-Reply-To: <20151215135907.GK29571@yliu-dev.sh.intel.com>
Hello!
> No idea. Maybe you have changed some other configures (such as of ovs)
> without notice? Or, the ovs bridge interface resets?
I don't touch the ovs at all. Just shut down the guest, rebuild the qemu, reinstall it, run the guest.
>
> BTW, would you please try my v1 patch set with above diff applied to
> see if the ping loss is still there. You might also want to run tcpdump
> with the dest host ovs bridge, to see if GARP is actually sent.
Retested with wireshark running on the host. I used my qemu patch instead, but it should not matter at all:
--- cut ---
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 1b6c5ac..5ca2987 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -480,7 +480,12 @@ static int vhost_user_get_u64(struct vhost_dev *dev, int request, uint64_t *u64)
static int vhost_user_get_features(struct vhost_dev *dev, uint64_t *features)
{
- return vhost_user_get_u64(dev, VHOST_USER_GET_FEATURES, features);
+ int ret = vhost_user_get_u64(dev, VHOST_USER_GET_FEATURES, features);
+
+ if (!ret) {
+ virtio_add_feature(features, VIRTIO_NET_F_GUEST_ANNOUNCE);
+ }
+ return ret;
}
static int vhost_user_set_owner(struct vhost_dev *dev)
--- cut ---
So, here are both wireshark captures on the host side:
1. Without the patch
root@nfv_test_x86_64 / # tshark -i ovs-br0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ovs-br0'
1 0.000000 :: -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
2 0.003304 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Reply)
3 0.669957 :: -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
4 0.858957 :: -> ff02::1:ff3b:831a ICMPv6 78 Neighbor Solicitation for fe80::5054:ff:fe3b:831a
5 1.858968 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
6 2.300948 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
7 2.527088 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
8 2.527800 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request)
9 6.526814 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
10 10.526993 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
11 15.984632 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
12 15.984643 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
13 15.984772 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x0477, seq=1/256, ttl=64
14 15.984798 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x0477, seq=1/256, ttl=64 (request in 13)
15 16.984970 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x0477, seq=2/512, ttl=64
16 16.984991 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x0477, seq=2/512, ttl=64 (request in 15)
17 17.984956 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x0477, seq=3/768, ttl=64
18 17.984975 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x0477, seq=3/768, ttl=64 (request in 17)
19 20.994535 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 Who has 192.168.6.2? Tell 192.168.6.1
20 20.994637 RealtekU_3b:83:1a -> be:e1:71:c1:47:4d ARP 42 192.168.6.2 is at 52:54:00:3b:83:1a
^C20 packets captured
2. With the patch
root@nfv_test_x86_64 / # tshark -i ovs-br0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ovs-br0'
1 0.000000 :: -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
2 0.000969 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Reply)
3 0.156966 :: -> ff02::1:ff3b:831a ICMPv6 78 Neighbor Solicitation for fe80::5054:ff:fe3b:831a
4 0.536948 :: -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
5 1.156968 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
6 1.312708 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
7 1.629960 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast Listener Report Message v2
8 2.314713 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request)
9 5.313333 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
10 9.315486 fe80::5054:ff:fe3b:831a -> ff02::2 ICMPv6 62 Router Solicitation
11 21.536450 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
12 21.536461 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
13 22.538937 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
14 22.538943 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
15 23.540937 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
16 23.540942 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
17 25.537519 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
18 25.537525 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
19 26.538939 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
20 26.538944 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
21 27.540937 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
22 27.540942 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
23 29.538475 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
24 29.538482 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
25 30.538935 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
26 30.538941 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
27 31.540935 RealtekU_3b:83:1a -> Broadcast ARP 42 Who has 192.168.6.1? Tell 192.168.6.2
28 31.540941 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at be:e1:71:c1:47:4d
^C28 packets captured
Obviously, the guest simply doesn't read incoming packets. ifconfig for the interface on guest side shows:
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 9 overruns 0 frame 9
BTW, number 9 exactly matches the number of ARP replies from the host. The question is - why? Looks like guest behavior changes
somehow. Is it a bug in guest? It's very strange, because in these sessions i see only one difference in IPv6 packets:
4 0.858957 :: -> ff02::1:ff3b:831a ICMPv6 78 Neighbor Solicitation for fe80::5054:ff:fe3b:831a
This is present in session #1 and missing from session #2. Can it affect the whole thing somehow? But i don't even use IPv6.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
next prev parent reply other threads:[~2015-12-15 14:58 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 8:26 [PATCH 0/4 for 2.3] vhost-user live migration support Pavel Fedin
2015-12-11 9:49 ` Yuanhan Liu
2015-12-11 10:22 ` Pavel Fedin
2015-12-14 3:58 ` Peter Xu
2015-12-14 7:30 ` Pavel Fedin
2015-12-14 9:04 ` Peter Xu
2015-12-14 9:46 ` Pavel Fedin
2015-12-14 10:09 ` Peter Xu
2015-12-14 12:09 ` Yuanhan Liu
2015-12-14 13:00 ` Peter Xu
2015-12-14 13:21 ` Yuanhan Liu
2015-12-14 13:28 ` Peter Xu
2015-12-14 13:51 ` Yuanhan Liu
2015-12-14 14:54 ` Pavel Fedin
2015-12-15 8:23 ` Yuanhan Liu
2015-12-15 8:45 ` Pavel Fedin
2015-12-15 8:56 ` Yuanhan Liu
2015-12-15 9:04 ` Pavel Fedin
2015-12-15 10:05 ` Peter Xu
2015-12-15 11:43 ` Thibaut Collet
2015-12-15 11:47 ` Thibaut Collet
2015-12-15 12:24 ` Pavel Fedin
2015-12-15 13:36 ` Yuanhan Liu
2015-12-15 13:48 ` Pavel Fedin
2015-12-15 13:59 ` Yuanhan Liu
2015-12-15 14:58 ` Pavel Fedin [this message]
2015-12-16 7:28 ` Yuanhan Liu
2015-12-16 11:57 ` Pavel Fedin
2015-12-16 12:08 ` Yuanhan Liu
2015-12-16 12:43 ` Pavel Fedin
2015-12-16 13:00 ` Yuanhan Liu
2015-12-15 13:18 ` Yuanhan Liu
2015-12-15 15:07 ` Thibaut Collet
2015-12-15 15:36 ` Pavel Fedin
2015-12-16 2:38 ` Peter Xu
2015-12-16 2:50 ` Yuanhan Liu
2015-12-16 7:05 ` Pavel Fedin
2015-12-15 9:42 ` Peter Xu
-- strict thread matches above, loose matches on Subject: below --
2015-12-02 3:43 Yuanhan Liu
2015-12-02 14:10 ` Victor Kaplansky
2015-12-02 14:33 ` Yuanhan Liu
2015-12-09 3:41 ` Xie, Huawei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00f101d13749$0eb97330$2c2c5990$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=dev@dpdk.org \
--cc=victork@redhat.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.