On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote: > On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote: > > > and the VM is not expected to do any tuning/optimizations on the VF driver > > > directly, > > > i think the current patch that follows the netvsc model of 2 > > > netdevs(virtio > > > and vf) should > > > work fine. > > > > OK. For your use case that's fine. But that's too specific scenario > > with lots of restrictions IMHO, perhaps very few users will benefit > > from it, I'm not sure. If you're unwilling to move towards it, we'd > > take this one and come back with a generic solution that is able to > > address general use cases for VF/PT live migration . > > I think that's a fine approach. Scratch your own itch! I imagine a very > generic virtio-switchdev providing host routing info to guests could > address lots of usecases. A driver could bind to that one and enslave > arbitrary other devices. Sounds reasonable. > > But given the fundamental idea of a failover was floated at least as > early as 2013, and made 0 progress since precisely because it kept > trying to address more and more features, and given netvsc is already > using the basic solution with some success, I'm not inclined to block > this specific effort waiting for the generic one.
I think there is an agreement that the extra netdev will be useful for more advanced use cases, and is generally preferable. What is the argument for not doing that from the start? If it was made I must have missed it. Is it just unwillingness to write the extra 300 lines of code? Sounds like a pretty weak argument when adding kernel ABI is at stake... _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
