From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by dpdk.org (Postfix) with ESMTP id 469853005 for ; Tue, 15 Dec 2015 16:07:58 +0100 (CET) Received: by mail-qg0-f46.google.com with SMTP id i91so1414328qgf.2 for ; Tue, 15 Dec 2015 07:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GL/7CMQjLN3wQwQUcfJP7MzwPVnrdNtGxPIJr9QhbQA=; b=CateP9bY8OMEDsKEesGPm5/VodHtSPIwqo7bs1nLvycSZbqNsiKxOPhpMDP9pUbt8u Sex/JxHCR1FnHd9q7Y5XTY6fJS5B46LiaOy6bzW6mORz8WvHLKCsktfSmKE+jWtLDHhw xNXlKyPh4Gjrf/7KIQ/Kxbhwkr5oNDrLQJaFuErlERSaxlR9GDoeMSI8XuPAGcah/z8q Y2povVM1nSx7645+Ohfftv71zQup4FU92usFcWr8eN6YIWZSvy7HV6v3Has+trTm7r0A 2PFVos09QmptwI1vvLiP7TZtf5buEp5+jfMW70U/ERM/PIHTHlNjsF0Mtqo5+BDAQfeN Ql2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GL/7CMQjLN3wQwQUcfJP7MzwPVnrdNtGxPIJr9QhbQA=; b=HckET1yj1YA32yx/2Yl7s8WIN9wRsJmyHk4NnzwnJTndC1YXazPXTApRTRb9BV9mDv Fmp6UwjLNAfH7suXiDemps91Q9xFSYAqPfYKRGk2wi9hRfZHiuLnvT9d+EQD9yQ2BPkt V5ov+SObj7a1AyHTX8zYaRw/8cfevnGzEJHg3E2lAaOA5uxdo9zdHVORqkCLrkW9jjzK U5U09fNqmcvSe694arXH2MSuZeHHEuUdd986GNEHy2IT0HYFxGqzr3i6gIvmqwLkRydn Ax2Fheif8wlzITELdV0NmFT18cZ0l24Lg8Kl7BNbL5UJvVWViZIMoz4C9JavMrfysogm 0G2Q== X-Gm-Message-State: ALoCoQmiP2LlkmWxdtY19XLjFnA5b+dc8fMWuYGjJ8qQy1gBcDD4nWLI5zfmpMSKyYUU6ur1U12T4REJhhVaIkI6mORY4GDdjYbZ0+IlG6aOfWt9dZLAXso= MIME-Version: 1.0 X-Received: by 10.140.89.201 with SMTP id v67mr53316483qgd.38.1450192077672; Tue, 15 Dec 2015 07:07:57 -0800 (PST) Received: by 10.140.98.193 with HTTP; Tue, 15 Dec 2015 07:07:57 -0800 (PST) In-Reply-To: <20151215131812.GI29571@yliu-dev.sh.intel.com> References: <000001d133ed$b2446eb0$16cd4c10$@samsung.com> <20151211094934.GX29571@yliu-dev.sh.intel.com> <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> <20151215131812.GI29571@yliu-dev.sh.intel.com> Date: Tue, 15 Dec 2015 16:07:57 +0100 Message-ID: From: Thibaut Collet To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 15:07:58 -0000 On Tue, Dec 15, 2015 at 2:18 PM, Yuanhan Liu wrote: > On Tue, Dec 15, 2015 at 12:47:47PM +0100, Thibaut Collet wrote: > > On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet < > thibaut.collet@6wind.com> > > wrote: > > > > > > > > > > > On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu wrote: > > > > > >> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote: > > >> > To tell the truth, i don't know. I am also learning qemu internals > on > > >> the fly. Indeed, i see that it should announce itself. But > > >> > this brings up a question: why do we need special announce > procedure in > > >> vhost-user then? > > >> > > >> I have the same question. Here is my guess... > > >> > > >> In customized networks, maybe people are not using ARP at all? When > > >> we use DPDK, we directly pass through the network logic inside > > >> kernel itself. So logically all the network protocols could be > > >> customized by the user of it. In the customized network, maybe there > > >> is some other protocol (rather than RARP) that would do the same > > >> thing as what ARP/RARP does. So, this SEND_RARP request could give > > >> the vhost-user backend a chance to format its own announce packet > > >> and broadcast (in the SEND_RARP request, the guest's mac address > > >> will be appended). > > >> > > >> CCing Victor to better know the truth... > > >> > > >> Peter > > >> > > > > > Hey Thibaut, > > First of all, thanks a lot for your lengthy explanation. > > > > Hi, > > > > > > After a migration, to avoid network outage, the guest must announce its > > > new location to the L2 layer, typically with a GARP. Otherwise requests > > > sent to the guest arrive to the old host until a ARP request is sent > (after > > > 30 seconds) or the guest sends some data. > > > > > > QEMU implementation of self announce after a migration with a vhost > > > backend is the following: > > > - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest > > > sends automatically a GARP. > > I'm kind of clear how VIRTIO_GUEST_ANNOUNCE works so far, except that I > met a bug, which I will describe in another email. > > > > - Else if the vhost backend implements VHOST_USER_SEND_RARP this > request > > > is sent to the vhost backend. When this message is received the vhost > > > backend must act as it receives a RARP from the guest (purpose of this > RARP > > Can you be more specific about this? Say, what kind of acts the vhost > backend should do exactly? > > > > is to update switches' MAC->port maaping as a GARP). > > Isn't it vhost library is not aware of swtich at all? How could we > update switches's MAC-port mapping inside vhost library? > > > This RARP is a false > > > one, created by the vhost backend, > > I'm a bit confused now. You were just saying "vhost backend must act > as it __recevives__ a RARP from the guest", and you are now saying > "the RARP is a false one __created__ by the vhost backend". > > Thanks. > > --yliu > After a migration, to avoid netwotk outage, all interfaces of the guest must send a packet to update switches mapping (ideally a GARP). As some interfaces do not do it QEMU does it in behalf of the guest by sending a RARP (his RARP is not forged by the guest but by QEMU). This is the qemu_self_announce purpose that "spoofs" a RARP to all backend of guest ethernet interfaces. For vhost-user backend, QEMU can not do it directly and asks to the vhost-user backend to do it with the VHOST_USER_SEND_RARP request that contains the MAC address of the guest interface. Thibaut.