From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available Date: Wed, 14 Mar 2018 02:44:23 +0200 Message-ID: <20180314024228-mutt-send-email-mst@kernel.org> References: <1519934923-39372-1-git-send-email-sridhar.samudrala@intel.com> <1519934923-39372-3-git-send-email-sridhar.samudrala@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Siwei Liu , Stephen Hemminger , David Miller , Netdev , Jiri Pirko , virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , Alexander Duyck , Jakub Kicinski To: "Samudrala, Sridhar" Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: List-Id: netdev.vger.kernel.org On Tue, Mar 13, 2018 at 05:28:07PM -0700, Samudrala, Sridhar wrote: > > I am not sure if it's a good idea to leave the > > virtio_bypass around if running into failure: the guest is not > > migratable as the VF doesn't have a backup path, > > Are you talking about a failure when registering backup netdev?  This should not > happen, but i guess we can improve error handling in such scenario. A nice way to do this would be to clear the backup feature bit. > > > And perhaps the worse > > part is that, it now has two interfaces with identical MAC address but > > one of them is invalid (user cannot use the virtio interface as it has > > a dampened datapath). IMHO the virtio_bypass and its lower netdev > > should be destroyed at all when it fails to bind the VF, and > > technically, there should be some way to propogate the failure status > > to the hypervisor/backend, indicating that the VM is not migratable > > because of guest software errors (maybe by clearing out the backup > > feature from the guest virtio driver so host can see/learn it). > > In BACKUP mode, user can only use the upper virtio_bypass netdev and that will > always be there. Any failure to enslave VF netdev is not fatal, but i will see > if we can improve the error handling of failure to enslave backup netdev. > Also, i don't think the BACKUP feature bit is negotiable with the host. > > Thanks > Sridhar All bits are negotiable. It's up to the host whether to support a device with this bit clear, or to fail negotiation. -- MST