From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753428AbbKYM2T (ORCPT ); Wed, 25 Nov 2015 07:28:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57190 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbbKYM2Q (ORCPT ); Wed, 25 Nov 2015 07:28:16 -0500 Date: Wed, 25 Nov 2015 14:28:05 +0200 From: "Michael S. Tsirkin" To: Lan Tianyu Cc: a.motakis@virtualopensystems.com, alex.williamson@redhat.com, b.reynal@virtualopensystems.com, bhelgaas@google.com, carolyn.wyborny@intel.com, donald.c.skidmore@intel.com, eddie.dong@intel.com, nrupal.jani@intel.com, agraf@suse.de, kvm@vger.kernel.org, pbonzini@redhat.com, qemu-devel@nongnu.org, emil.s.tantilov@intel.com, gerlitz.or@gmail.com, mark.d.rustad@intel.com, eric.auger@linaro.org, intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com, jesse.brandeburg@intel.com, john.ronciak@intel.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, matthew.vick@intel.com, mitch.a.williams@intel.com, netdev@vger.kernel.org, shannon.nelson@intel.com, weiyang@linux.vnet.ibm.com, zajec5@gmail.com Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Message-ID: <20151125142437-mutt-send-email-mst@redhat.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56554994.1090305@intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 25, 2015 at 01:39:32PM +0800, Lan Tianyu wrote: > On 2015年11月25日 05:20, Michael S. Tsirkin wrote: > > I have to say, I was much more interested in the idea > > of tracking dirty memory. I have some thoughts about > > that one - did you give up on it then? > > No, our finial target is to keep VF active before doing > migration and tracking dirty memory is essential. But this > seems not easy to do that in short term for upstream. As > starters, stop VF before migration. Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. Also, assuming you just want to do ifdown/ifup for some reason, it's easy enough to do using a guest agent, in a completely generic way. > After deep thinking, the way of stopping VF still needs tracking > DMA-accessed dirty memory to make sure the received data buffer > before stopping VF migrated. It's easier to do that via dummy writing > data buffer when receive packet. > > > -- > Best regards > Tianyu Lan From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ZBM-0007CX-8s for qemu-devel@nongnu.org; Wed, 25 Nov 2015 07:28:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1ZBJ-0000Mi-1M for qemu-devel@nongnu.org; Wed, 25 Nov 2015 07:28:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ZBI-0000Me-Rf for qemu-devel@nongnu.org; Wed, 25 Nov 2015 07:28:16 -0500 Date: Wed, 25 Nov 2015 14:28:05 +0200 From: "Michael S. Tsirkin" Message-ID: <20151125142437-mutt-send-email-mst@redhat.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56554994.1090305@intel.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lan Tianyu Cc: weiyang@linux.vnet.ibm.com, emil.s.tantilov@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, jesse.brandeburg@intel.com, mark.d.rustad@intel.com, carolyn.wyborny@intel.com, eric.auger@linaro.org, donald.c.skidmore@intel.com, zajec5@gmail.com, agraf@suse.de, matthew.vick@intel.com, intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com, gerlitz.or@gmail.com, mitch.a.williams@intel.com, nrupal.jani@intel.com, bhelgaas@google.com, a.motakis@virtualopensystems.com, b.reynal@virtualopensystems.com, linux-api@vger.kernel.org, shannon.nelson@intel.com, eddie.dong@intel.com, alex.williamson@redhat.com, linux-kernel@vger.kernel.org, john.ronciak@intel.com, netdev@vger.kernel.org, pbonzini@redhat.com On Wed, Nov 25, 2015 at 01:39:32PM +0800, Lan Tianyu wrote: > On 2015=E5=B9=B411=E6=9C=8825=E6=97=A5 05:20, Michael S. Tsirkin wrote: > > I have to say, I was much more interested in the idea > > of tracking dirty memory. I have some thoughts about > > that one - did you give up on it then? >=20 > No, our finial target is to keep VF active before doing > migration and tracking dirty memory is essential. But this > seems not easy to do that in short term for upstream. As > starters, stop VF before migration. Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. Also, assuming you just want to do ifdown/ifup for some reason, it's easy enough to do using a guest agent, in a completely generic way. > After deep thinking, the way of stopping VF still needs tracking > DMA-accessed dirty memory to make sure the received data buffer > before stopping VF migrated. It's easier to do that via dummy writing > data buffer when receive packet. >=20 >=20 > --=20 > Best regards > Tianyu Lan From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Date: Wed, 25 Nov 2015 14:28:05 +0200 Message-ID: <20151125142437-mutt-send-email-mst@redhat.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org, alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, carolyn.wyborny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, nrupal.jani-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, agraf-l3A5Bk7waGM@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org, emil.s.tantilov-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, mark.d.rustad-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, intel-wired-lan-qjLDD68F18P21nG7glBr7A@public.gmane.org, jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, john.ronciak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, matthew.vick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mitch.a.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shannon.nelson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, weiyang-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org To: Lan Tianyu Return-path: Content-Disposition: inline In-Reply-To: <56554994.1090305-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Wed, Nov 25, 2015 at 01:39:32PM +0800, Lan Tianyu wrote: > On 2015=E5=B9=B411=E6=9C=8825=E6=97=A5 05:20, Michael S. Tsirkin wrot= e: > > I have to say, I was much more interested in the idea > > of tracking dirty memory. I have some thoughts about > > that one - did you give up on it then? >=20 > No, our finial target is to keep VF active before doing > migration and tracking dirty memory is essential. But this > seems not easy to do that in short term for upstream. As > starters, stop VF before migration. =46rankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. Also, assuming you just want to do ifdown/ifup for some reason, it's easy enough to do using a guest agent, in a completely generic way. > After deep thinking, the way of stopping VF still needs tracking > DMA-accessed dirty memory to make sure the received data buffer > before stopping VF migrated. It's easier to do that via dummy writing > data buffer when receive packet. >=20 >=20 > --=20 > Best regards > Tianyu Lan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael S. Tsirkin Date: Wed, 25 Nov 2015 14:28:05 +0200 Subject: [Intel-wired-lan] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver In-Reply-To: <56554994.1090305@intel.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> Message-ID: <20151125142437-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Wed, Nov 25, 2015 at 01:39:32PM +0800, Lan Tianyu wrote: > On 2015?11?25? 05:20, Michael S. Tsirkin wrote: > > I have to say, I was much more interested in the idea > > of tracking dirty memory. I have some thoughts about > > that one - did you give up on it then? > > No, our finial target is to keep VF active before doing > migration and tracking dirty memory is essential. But this > seems not easy to do that in short term for upstream. As > starters, stop VF before migration. Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. Also, assuming you just want to do ifdown/ifup for some reason, it's easy enough to do using a guest agent, in a completely generic way. > After deep thinking, the way of stopping VF still needs tracking > DMA-accessed dirty memory to make sure the received data buffer > before stopping VF migrated. It's easier to do that via dummy writing > data buffer when receive packet. > > > -- > Best regards > Tianyu Lan