From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id 33468370 for ; Tue, 22 Dec 2015 09:24:28 +0100 (CET) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NZR000XF3CQIX80@mailout3.w1.samsung.com> for dev@dpdk.org; Tue, 22 Dec 2015 08:24:26 +0000 (GMT) X-AuditID: cbfec7f4-f79026d00000418a-02-567908bac54e Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 31.0C.16778.AB809765; Tue, 22 Dec 2015 08:24:26 +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 <0NZR0075G3CPCL80@eusync3.samsung.com>; Tue, 22 Dec 2015 08:24:26 +0000 (GMT) From: Pavel Fedin To: 'Peter Xu' , 'Yuanhan Liu' References: <1449027793-30975-1-git-send-email-yuanhan.liu@linux.intel.com> <1450321921-27799-1-git-send-email-yuanhan.liu@linux.intel.com> <1450321921-27799-6-git-send-email-yuanhan.liu@linux.intel.com> <20151222081108.GF7532@pxdev.xzpeter.org> In-reply-to: <20151222081108.GF7532@pxdev.xzpeter.org> Date: Tue, 22 Dec 2015 11:24:25 +0300 Message-id: <004401d13c92$2b9d35b0$82d7a110$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQKk4gwff5b91BWl/5G7CjZG6+2D3wI+GqRzAYYkNxQBsX96Op0DsI9w Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsVy+t/xq7q7OCrDDL7eULPY3Chs8e7TdiaL 9plnmSz+/3rFarFl/zd2i8mfl7NaXJ9wgdWB3ePXgqWsHov3vGTymHcy0OP9vqtsASxRXDYp qTmZZalF+nYJXBlbW5ayF7zmqZi0fxVbA+M2ri5GTg4JAROJT0ePsUDYYhIX7q1n62Lk4hAS WMoocWf+bGYI5zujxKvd85hBqtgE1CVOf/0A1iEi4C8xcd9DdpAiZoFNjBI7/zUyQnT8ZpSY frcXaBYHB6eAmcSGOXEgDcJADfe6doE1swioSiy728cEYvMKWEqsXtbFDGELSvyYfA+shhlo 2aR5i5ghbG2JJ+8usEKcqiCx4+xrRogj3CSen5sKVS8iMe3fPeYJjEKzkIyahWTULCSjZiFp WcDIsopRNLU0uaA4KT3XUK84Mbe4NC9dLzk/dxMjJEq+7GBcfMzqEKMAB6MSD++EBRVhQqyJ ZcWVuYcYJTiYlUR4Bdkqw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzzt31PkRIID2xJDU7NbUg tQgmy8TBKdXAKK30v/312fyrQXGWZ7qfWs7QyZHWv9DgfFbR9E8sz45NCy1OBe8zzvxcstH6 sF9AFbNGzYmY2RoMaxjb51em37u2eeFJjZdnZ8SJKYjvW7qjcmJ3893D/hF1W6/dOcdgdmr2 6bPpR3zSzz5hDdWaf3Ld0YTpst27clYkhLhNEPv1SJDp6xvvYCWW4oxEQy3mouJEAPazzMSO AgAA Cc: dev@dpdk.org, 'Victor Kaplansky' , "'Michael S. Tsirkin'" Subject: Re: [dpdk-dev] [PATCH v2 5/6] vhost: claim that we support GUEST_ANNOUNCE feature 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, 22 Dec 2015 08:24:28 -0000 Hello! > > diff --git a/lib/librte_vhost/virtio-net.c = b/lib/librte_vhost/virtio-net.c > > index 03044f6..0ba5045 100644 > > --- a/lib/librte_vhost/virtio-net.c > > +++ b/lib/librte_vhost/virtio-net.c > > @@ -74,6 +74,7 @@ static struct virtio_net_config_ll *ll_root; > > #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) = | \ > > (1ULL << VIRTIO_NET_F_CTRL_VQ) | \ > > (1ULL << VIRTIO_NET_F_CTRL_RX) | \ > > + (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \ >=20 > Do we really need this? I can understand when guest declare with > this VIRTIO_NET_F_GUEST_ANNOUNCE flag. With that, guest itself will > handle the announcement after migration. However, how could I > understand if it's declared by a vhost-user backend? I guess the documentation is unclear. This is due to way how qemu = works. It queries vhost-user backend for the features, then offers them = to the guest. The guest then responds with features FROM THE SUGGESTED = SET, which it supports. So, if the backend does not claim to support = this feature, qemu will not offer it to the guest, therefore the guest = will not try to activate it. I think this is done because this feature is only useful for migration. = If vhost-user backend does not support migration, it needs neither = VHOST_USER_SEND_RARP nor guest-side announce. Actually, i was thinking about patching qemu once, but... The changeset = seemed too complicated, and i imagined the situation described in the = above sentence, so decided to abandon it. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia