From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4DEEA1B010 for ; Tue, 9 Jan 2018 09:49:38 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8BF072BA1; Tue, 9 Jan 2018 08:49:37 +0000 (UTC) Received: from [10.36.112.39] (ovpn-112-39.ams2.redhat.com [10.36.112.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FDA366A1B; Tue, 9 Jan 2018 08:49:36 +0000 (UTC) To: Xiao Wang , yliu@fridaylinux.org Cc: tiwei.bie@intel.com, dev@dpdk.org, stephen@networkplumber.org References: <20180107120513.142196-3-xiao.w.wang@intel.com> <20180109142651.84582-1-xiao.w.wang@intel.com> <20180109142651.84582-4-xiao.w.wang@intel.com> From: Maxime Coquelin Message-ID: Date: Tue, 9 Jan 2018 09:49:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180109142651.84582-4-xiao.w.wang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 09 Jan 2018 08:49:37 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v7 3/3] net/virtio: support GUEST ANNOUNCE X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 08:49:38 -0000 On 01/09/2018 03:26 PM, Xiao Wang wrote: > When live migration is done, for the backup VM, either the virtio > frontend or the vhost backend needs to send out gratuitous RARP packet > to announce its new network location. > > This patch enables VIRTIO_NET_F_GUEST_ANNOUNCE feature to support live > migration scenario where the vhost backend doesn't have the ability to > generate RARP packet. > > Brief introduction of the work flow: > 1. QEMU finishes live migration, pokes the backup VM with an interrupt. > 2. Virtio interrupt handler reads out the interrupt status value, and > realizes it needs to send out RARP packet to announce its location. > 3. Pause device to stop worker thread touching the queues. > 4. Inject a RARP packet into a Tx Queue. > 5. Ack the interrupt via control queue. > 6. Resume device to continue packet processing. > > Signed-off-by: Xiao Wang > --- > drivers/net/virtio/virtio_ethdev.c | 95 +++++++++++++++++++++++++++++++++++++- > drivers/net/virtio/virtio_ethdev.h | 1 + > drivers/net/virtio/virtqueue.h | 11 +++++ > 3 files changed, 105 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c > index e8ff1e449..9606df514 100644 > --- a/drivers/net/virtio/virtio_ethdev.c > +++ b/drivers/net/virtio/virtio_ethdev.c > @@ -19,6 +19,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -78,6 +80,11 @@ static int virtio_dev_queue_stats_mapping_set( > uint8_t stat_idx, > uint8_t is_rx); > > +static int make_rarp_packet(struct rte_mbuf *rarp_mbuf, > + const struct ether_addr *mac); > +static void virtio_notify_peers(struct rte_eth_dev *dev); > +static void virtio_ack_link_announce(struct rte_eth_dev *dev); > + > /* > * The set of PCI devices this driver supports > */ > @@ -1272,9 +1279,89 @@ virtio_inject_pkts(struct rte_eth_dev *dev, struct rte_mbuf **tx_pkts, > return ret; > } > > +#define RARP_PKT_SIZE 64 > +static int > +make_rarp_packet(struct rte_mbuf *rarp_mbuf, const struct ether_addr *mac) > +{ > + struct ether_hdr *eth_hdr; > + struct arp_hdr *rarp; > + > + if (rarp_mbuf->buf_len < RARP_PKT_SIZE) { > + PMD_DRV_LOG(ERR, "mbuf size too small %u (< %d)", > + rarp_mbuf->buf_len, RARP_PKT_SIZE); > + return -1; > + } > + > + /* Ethernet header. */ > + eth_hdr = rte_pktmbuf_mtod(rarp_mbuf, struct ether_hdr *); > + memset(eth_hdr->d_addr.addr_bytes, 0xff, ETHER_ADDR_LEN); > + ether_addr_copy(mac, ð_hdr->s_addr); > + eth_hdr->ether_type = htons(ETHER_TYPE_RARP); > + > + /* RARP header. */ > + rarp = (struct arp_hdr *)(eth_hdr + 1); > + rarp->arp_hrd = htons(ARP_HRD_ETHER); > + rarp->arp_pro = htons(ETHER_TYPE_IPv4); > + rarp->arp_hln = ETHER_ADDR_LEN; > + rarp->arp_pln = 4; > + rarp->arp_op = htons(ARP_OP_REVREQUEST); > + > + ether_addr_copy(mac, &rarp->arp_data.arp_sha); > + ether_addr_copy(mac, &rarp->arp_data.arp_tha); > + memset(&rarp->arp_data.arp_sip, 0x00, 4); > + memset(&rarp->arp_data.arp_tip, 0x00, 4); > + > + rarp_mbuf->data_len = RARP_PKT_SIZE; > + rarp_mbuf->pkt_len = RARP_PKT_SIZE; > + > + return 0; > +} Do you think it could make sense to have this function in a lib, as vhost user lib does exactly the same? I don't know if it could be useful to others than vhost/virtio though. Thanks, Maxime