From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alejandro Lucero Subject: Re: [PATCH 6/9] net/ifc: add devarg for LM mode Date: Wed, 12 Dec 2018 10:15:17 +0000 Message-ID: References: <20181128094607.106173-1-xiao.w.wang@intel.com> <20181128094607.106173-7-xiao.w.wang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: tiwei.bie@intel.com, Maxime Coquelin , dev , zhihong.wang@intel.com, xiaolong.ye@intel.com To: xiao.w.wang@intel.com Return-path: Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by dpdk.org (Postfix) with ESMTP id 113382C12 for ; Wed, 12 Dec 2018 11:15:24 +0100 (CET) Received: by mail-ed1-f67.google.com with SMTP id f23so15077871edb.3 for ; Wed, 12 Dec 2018 02:15:24 -0800 (PST) In-Reply-To: <20181128094607.106173-7-xiao.w.wang@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Nov 28, 2018 at 9:56 AM Xiao Wang wrote: > This patch series enables a new method for live migration, i.e. software > assisted live migration. This patch provides a device argument for user > to choose the methold. > > When "swlm=1", driver/device will do live migration with a relay thread > dealing with dirty page logging. Without this parameter, device will do > dirty page logging and there's no relay thread consuming CPU resource. > > I'm a bit confused with this mode. If it is a relay thread doing the dirty page logging, does it mean that the datapath is through the relay thread and not between the VM and the vdpa device? > Signed-off-by: Xiao Wang > --- > drivers/net/ifc/ifcvf_vdpa.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c > index c0e50354a..e9cc8d7bc 100644 > --- a/drivers/net/ifc/ifcvf_vdpa.c > +++ b/drivers/net/ifc/ifcvf_vdpa.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -31,9 +32,11 @@ > #endif > > #define IFCVF_VDPA_MODE "vdpa" > +#define IFCVF_SW_FALLBACK_LM "swlm" > > static const char * const ifcvf_valid_arguments[] = { > IFCVF_VDPA_MODE, > + IFCVF_SW_FALLBACK_LM, > NULL > }; > > @@ -56,6 +59,7 @@ struct ifcvf_internal { > rte_atomic32_t dev_attached; > rte_atomic32_t running; > rte_spinlock_t lock; > + bool sw_lm; > }; > > struct internal_list { > @@ -767,6 +771,7 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv > __rte_unused, > struct ifcvf_internal *internal = NULL; > struct internal_list *list = NULL; > int vdpa_mode = 0; > + int sw_fallback_lm = 0; > struct rte_kvargs *kvlist = NULL; > int ret = 0; > > @@ -826,6 +831,16 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv > __rte_unused, > internal->dev_addr.type = PCI_ADDR; > list->internal = internal; > > + if (rte_kvargs_count(kvlist, IFCVF_SW_FALLBACK_LM)) { > + ret = rte_kvargs_process(kvlist, IFCVF_SW_FALLBACK_LM, > + &open_int, &sw_fallback_lm); > + if (ret < 0) > + goto error; > + internal->sw_lm = sw_fallback_lm ? true : false; > + } else { > + internal->sw_lm = false; > + } > + > internal->did = rte_vdpa_register_device(&internal->dev_addr, > &ifcvf_ops); > if (internal->did < 0) { > -- > 2.15.1 > >