From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by dpdk.org (Postfix) with ESMTP id 871BD3005 for ; Tue, 15 Dec 2015 15:58:30 +0100 (CET) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NZE00DAYMXHMO10@mailout4.w1.samsung.com> for dev@dpdk.org; Tue, 15 Dec 2015 14:58:29 +0000 (GMT) X-AuditID: cbfec7f4-f79026d00000418a-30-56702a95d3ae Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 8E.86.16778.59A20765; Tue, 15 Dec 2015 14:58:29 +0000 (GMT) Received: from fedinw7x64 ([106.109.131.169]) by eusync3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NZE009B0MXGHD50@eusync3.samsung.com>; Tue, 15 Dec 2015 14:58:29 +0000 (GMT) From: Pavel Fedin To: 'Yuanhan Liu' References: <001c01d133fd$d3a7d870$7af78950$@samsung.com> <20151214035842.GB18437@pxdev.xzpeter.org> <20151215082324.GG29571@yliu-dev.sh.intel.com> <007f01d13715$042a0a80$0c7e1f80$@samsung.com> <20151215100548.GD32243@pxdev.xzpeter.org> <00b601d13733$97e063a0$c7a12ae0$@samsung.com> <20151215133612.GJ29571@yliu-dev.sh.intel.com> <00ca01d1373f$3dd4ab30$b97e0190$@samsung.com> <20151215135907.GK29571@yliu-dev.sh.intel.com> In-reply-to: <20151215135907.GK29571@yliu-dev.sh.intel.com> Date: Tue, 15 Dec 2015 17:58:28 +0300 Message-id: <00f101d13749$0eb97330$2c2c5990$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHzj+BTsNZi3NbbjRFIXoRaVEgjWwH1YLgUAr1X7FkA1t9fGQLUijOVAXicbVECIEDj0AJNjjn7AoA+XEMB0EW0qAHYKet/neQE88A= Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsVy+t/xq7pTtQrCDC4/VbB492k7k8WW/d/Y Lbp77rFbLD5wmNni+oQLrA6sHhf77zB6/FqwlNVj3slAj/f7rrIFsERx2aSk5mSWpRbp2yVw ZUztb2cv6LGo+PHxA1MD41udLkZODgkBE4nZLQvYIWwxiQv31rN1MXJxCAksZZT4eGkTM4Tz nVHiw/FfTCBVbALqEqe/fmABsUUE9CU+bW1lASliFuhilOieMg+q4wiLxK99+1lBqjgFrCUa T65mBrGFBXwlXi59AjaJRUBVYteeG2CTeAUsJX7MecEGYQtK/Jh8DyzOLKAlsX7ncSYIW15i 85q3zBC3KkjsOPuaEeKKConp0/ezQ9SISEz7d495AqPQLCSjZiEZNQvJqFlIWhYwsqxiFE0t TS4oTkrPNdQrTswtLs1L10vOz93ECImKLzsYFx+zOsQowMGoxMP7gzU/TIg1say4MvcQowQH s5II70X1gjAh3pTEyqrUovz4otKc1OJDjNIcLErivHN3vQ8REkhPLEnNTk0tSC2CyTJxcEo1 MM5S7lDq+zWviEn48wk9jeYfJZ0vduxu/Lr0wfQj0qU7L+2Trv3190iTaNu7rq74bI9LT1Mv HvrbsvN9lsdCsayd9nv89MuS3frTV7q5tK+b4VXaaplYcOni/xtnOioWdHrxLT4Ts/P8b9dF sxaLzRFlWXp1V6Pnnyt3C95+k2tdl8DgfLZ2fbASS3FGoqEWc1FxIgAGRwe/hgIAAA== Cc: dev@dpdk.org, 'Victor Kaplansky' Subject: Re: [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 14:58:30 -0000 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