From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH net-next v9 3/4] virtio_net: Extend virtio to use VF datapath when available Date: Sun, 29 Apr 2018 15:45:02 +0200 Message-ID: <20180429134502.GA23854@nanopsycho.orion> References: <1524848820-42258-1-git-send-email-sridhar.samudrala@intel.com> <1524848820-42258-4-git-send-email-sridhar.samudrala@intel.com> <20180428094205.GM5632@nanopsycho.orion> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sridhar Samudrala , "Michael S. Tsirkin" , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , Alexander Duyck , Jakub Kicinski , Jason Wang , aaron.f.brown@intel.com To: Siwei Liu Return-path: Received: from mail-wr0-f174.google.com ([209.85.128.174]:40161 "EHLO mail-wr0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752895AbeD2NpH (ORCPT ); Sun, 29 Apr 2018 09:45:07 -0400 Received: by mail-wr0-f174.google.com with SMTP id v60-v6so5729387wrc.7 for ; Sun, 29 Apr 2018 06:45:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Sun, Apr 29, 2018 at 10:56:30AM CEST, loseweigh@gmail.com wrote: >On Sat, Apr 28, 2018 at 2:42 AM, Jiri Pirko wrote: >> Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudrala@intel.com wrote: >>>This patch enables virtio_net to switch over to a VF datapath when a VF >>>netdev is present with the same MAC address. It allows live migration >>>of a VM with a direct attached VF without the need to setup a bond/team >>>between a VF and virtio net device in the guest. >>> >>>The hypervisor needs to enable only one datapath at any time so that >>>packets don't get looped back to the VM over the other datapath. When a VF >>>is plugged, the virtio datapath link state can be marked as down. The >>>hypervisor needs to unplug the VF device from the guest on the source host >>>and reset the MAC filter of the VF to initiate failover of datapath to >>>virtio before starting the migration. After the migration is completed, >>>the destination hypervisor sets the MAC filter on the VF and plugs it back >>>to the guest to switch over to VF datapath. >>> >>>It uses the generic failover framework that provides 2 functions to create >>>and destroy a master failover netdev. When STANDBY feature is enabled, an >>>additional netdev(failover netdev) is created that acts as a master device >>>and tracks the state of the 2 lower netdevs. The original virtio_net netdev >>>is marked as 'standby' netdev and a passthru device with the same MAC is >>>registered as 'primary' netdev. >>> >>>This patch is based on the discussion initiated by Jesse on this thread. >>>https://marc.info/?l=linux-virtualization&m=151189725224231&w=2 >>> >> >> When I enabled the standby feature (hardcoded), I have 2 netdevices now: >> 4: ens3: mtu 1500 qdisc noqueue state UP group default qlen 1000 >> link/ether 52:54:00:b2:a7:f1 brd ff:ff:ff:ff:ff:ff >> inet6 fe80::5054:ff:feb2:a7f1/64 scope link >> valid_lft forever preferred_lft forever >> 5: ens3n_sby: mtu 1500 qdisc fq_codel state UP group default qlen 1000 >> link/ether 52:54:00:b2:a7:f1 brd ff:ff:ff:ff:ff:ff >> inet6 fe80::5054:ff:feb2:a7f1/64 scope link >> valid_lft forever preferred_lft forever >> >> However, it seems to confuse my initscripts on Fedora: >> [root@test1 ~]# ifup ens3 >> ./network-functions: line 78: [: /etc/dhcp/dhclient-ens3: binary operator expected >> ./network-functions: line 80: [: /etc/dhclient-ens3: binary operator expected >> ./network-functions: line 69: [: /var/lib/dhclient/dhclient-ens3: binary operator expected >> >You should teach Fedora and all cloud vendors to upgrade their >initscripts and other userspace tools, no? I just wanted to point out that the conversion from "nostandby" to "standby" isn't always that smooth as claimed. The claim was "no change for the current user" iirc.