From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 7E8D5378E for ; Thu, 24 Nov 2016 16:25:12 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 24 Nov 2016 07:24:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,543,1473145200"; d="scan'208";a="1089961583" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga002.fm.intel.com with ESMTP; 24 Nov 2016 07:24:54 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX106.ger.corp.intel.com ([169.254.8.112]) with mapi id 14.03.0248.002; Thu, 24 Nov 2016 15:24:52 +0000 From: "Kavanagh, Mark B" To: Kevin Traynor , Maxime Coquelin , Yuanhan Liu , "Weglicki, MichalX" CC: "Michael S. Tsirkin" , "dev@dpdk.org" , Stephen Hemminger , "qemu-devel@nongnu.org" , "libvir-list@redhat.com" , "vpp-dev@lists.fd.io" , =?iso-8859-1?Q?Marc-Andr=E9_Lureau?= Thread-Topic: [dpdk-dev] dpdk/vpp and cross-version migration for vhost Thread-Index: AQHSJXpnwaeQO/w0k0ajapzKNWUo66DdDlgAgAAFEICAABFyAIAAgqKAgAeO44CAAB7ugIACmIWAgAAyG4CAADLrAIAABCUAgAAlZwCAAAS48A== Date: Thu, 24 Nov 2016 15:24:52 +0000 Message-ID: References: <20161011173526-mutt-send-email-mst@kernel.org> <20161117082902.GM5048@yliu-dev.sh.intel.com> <20161117094936.GN5048@yliu-dev.sh.intel.com> <20161117192445-mutt-send-email-mst@kernel.org> <20161122130223.GW5048@yliu-dev.sh.intel.com> <20161122164143-mutt-send-email-mst@kernel.org> <20161124063129.GE5048@yliu-dev.sh.intel.com> <4d6e8cf0-fe19-43a9-ff73-c2a9cdeb681e@redhat.com> <20161124123304.GG5048@yliu-dev.sh.intel.com> <0f83baa0-206e-4af2-1a97-d59c8e0582b8@redhat.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjE1NGYyYzctZjQwYy00NGE5LWI1ZWItODQxNTZlNmRhZGZjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InhJdTdTbWNwWU0xS0FZSXJRR3cxZWhra0NJWTNQYTF6YWViVk9MeVVxNW89In0= x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] dpdk/vpp and cross-version migration for vhost 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: Thu, 24 Nov 2016 15:25:13 -0000 > >On 11/24/2016 12:47 PM, Maxime Coquelin wrote: >> >> >> On 11/24/2016 01:33 PM, Yuanhan Liu wrote: >>> On Thu, Nov 24, 2016 at 09:30:49AM +0000, Kevin Traynor wrote: >>>> > On 11/24/2016 06:31 AM, Yuanhan Liu wrote: >>>>> > > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrot= e: >>>>>>>> > >>>> You keep assuming that you have the VM started first and >>>>>>>> > >>>> figure out things afterwards, but this does not work. >>>>>>>> > >>>> >>>>>>>> > >>>> Think about a cluster of machines. You want to start a VM i= n >>>>>>>> > >>>> a way that will ensure compatibility with all hosts >>>>>>>> > >>>> in a cluster. >>>>>>> > >>> >>>>>>> > >>> I see. I was more considering about the case when the dst >>>>>>> > >>> host (including the qemu and dpdk combo) is given, and >>>>>>> > >>> then determine whether it will be a successfull migration >>>>>>> > >>> or not. >>>>>>> > >>> >>>>>>> > >>> And you are asking that we need to know which host could >>>>>>> > >>> be a good candidate before starting the migration. In such >>>>>>> > >>> case, we indeed need some inputs from both the qemu and >>>>>>> > >>> vhost-user backend. >>>>>>> > >>> >>>>>>> > >>> For DPDK, I think it could be simple, just as you said, it >>>>>>> > >>> could be either a tiny script, or even a macro defined in >>>>>>> > >>> the source code file (we extend it every time we add a >>>>>>> > >>> new feature) to let the libvirt to read it. Or something >>>>>>> > >>> else. >>>>>> > >> >>>>>> > >> There's the issue of APIs that tweak features as Maxime >>>>>> > >> suggested. >>>>> > > >>>>> > > Yes, it's a good point. >>>>> > > >>>>>> > >> Maybe the only thing to do is to deprecate it, >>>>> > > >>>>> > > Looks like so. >>>>> > > >>>>>> > >> but I feel some way for application to pass info into >>>>>> > >> guest might be benefitial. >>>>> > > >>>>> > > The two APIs are just for tweaking feature bits DPDK supports >>>>> before >>>>> > > any device got connected. It's another way to disable some featur= es >>>>> > > (the another obvious way is to through QEMU command lines). >>>>> > > >>>>> > > IMO, it's bit handy only in a case like: we have bunch of VMs. >>>>> Instead >>>>> > > of disabling something though qemu one by one, we could disable i= t >>>>> > > once in DPDK. >>>>> > > >>>>> > > But I doubt the useful of it. It's only used in DPDK's vhost >>>>> example >>>>> > > after all. Nor is it used in vhost pmd, neither is it used in OVS= . >>>> > >>>> > rte_vhost_feature_disable() is currently used in OVS, >>>> lib/netdev-dpdk.c >>> Hmmm. I must have checked very old code ... >>>> > >>>> > netdev_dpdk_vhost_class_init(void) >>>> > { >>>> > static struct ovsthread_once once =3D OVSTHREAD_ONCE_INITIALIZER= ; >>>> > >>>> > /* This function can be called for different classes. The >>>> > initialization >>>> > * needs to be done only once */ >>>> > if (ovsthread_once_start(&once)) { >>>> > rte_vhost_driver_callback_register(&virtio_net_device_ops); >>>> > rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4 >>>> > | 1ULL << VIRTIO_NET_F_HOST_TSO6 >>>> > | 1ULL << VIRTIO_NET_F_CSUM); >>> I saw the commit introduced such change, but it tells no reason why >>> it was added. >> >> I'm also interested to know the reason. > >I can't remember off hand, added Mark K or Michal W who should be able >to shed some light on it. DPDK v16.04 added support for vHost User TSO; as such, by default, TSO is a= dvertised to guest devices as an available feature during feature negotiati= on with QEMU. However, while the vHost user backend sets up the majority of the mbuf fiel= ds that are required for TSO, there is still a reliance on the associated D= PDK application (i.e. in this case OvS-DPDK) to set the remaining flags and= /or offsets. Since OvS-DPDK doesn't currently provide that functionality, i= t is necessary to explicitly disable TSO; otherwise, undefined behaviour wi= ll ensue. > >> In any case, I think this is something that can/should be managed by >> the management tool, which should disable it in cmd parameters. >> >> Kevin, do you agree? > >I think best to find out the reason first. Because if no reason to >disable in the code, then no need to debate! > >> >> Cheers, >> Maxime