From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available Date: Sun, 28 Jan 2018 15:02:37 -0800 Message-ID: <20180128150237.35237d84@xeon-e3> References: <1515736720-39368-1-git-send-email-sridhar.samudrala@intel.com> <1515736720-39368-3-git-send-email-sridhar.samudrala@intel.com> <20180122233205-mutt-send-email-mst@kernel.org> <20180124004556-mutt-send-email-mst@kernel.org> <731db0a0-85e7-a88e-6e0e-c540086347b5@intel.com> <20180127000831-mutt-send-email-mst@kernel.org> <20180126144704.6e1a9628@cakuba.netronome.com> <5fa8c6c6-4a94-91fa-fdbb-ee7b624d703f@intel.com> <20180126183003.591cd5c5@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Samudrala, Sridhar" , "Michael S. Tsirkin" , Siwei Liu , David Miller , Netdev , virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" , Alexander Duyck To: Jakub Kicinski Return-path: Received: from mail-pg0-f68.google.com ([74.125.83.68]:35503 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933142AbeA1XCl (ORCPT ); Sun, 28 Jan 2018 18:02:41 -0500 Received: by mail-pg0-f68.google.com with SMTP id o13so2995819pgs.2 for ; Sun, 28 Jan 2018 15:02:41 -0800 (PST) In-Reply-To: <20180126183003.591cd5c5@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 26 Jan 2018 18:30:03 -0800 Jakub Kicinski wrote: > On Fri, 26 Jan 2018 15:30:35 -0800, Samudrala, Sridhar wrote: > > On 1/26/2018 2:47 PM, Jakub Kicinski wrote: =20 > > > On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote: =20 > > >> On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote: =20 > > >>>> and the VM is not expected to do any tuning/optimizations on the V= F driver > > >>>> directly, > > >>>> i think the current patch that follows the netvsc model of 2 netde= vs(virtio > > >>>> and vf) should > > >>>> work fine. =20 > > >>> 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 . =20 > > >> 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. =20 > > > 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 ha= ve > > > 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... =20 > >=20 > > I am still not clear on the need for the extra netdev created by=20 > > virtio_net. The only advantage i can see is that the stats can be > > broken between VF and virtio datapaths compared to the aggregrated > > stats on virtio netdev as seen with the 2 netdev approach. =20 >=20 > Maybe you're not convinced but multiple arguments were made. >=20 > > With 2 netdev model, any VM image that has a working network=20 > > configuration will transparently get VF based acceleration without > > any changes. =20 >=20 > Nothing happens transparently. Things may happen automatically. The > VF netdev doesn't disappear with netvsc. The PV netdev transforms into > something it did not use to be. And configures and reports some > information from the PV (e.g. speed) but PV doesn't pass traffic any > longer. >=20 > > 3 netdev model breaks this configuration starting with the creation > > and naming of the 2 devices to udev needing to be aware of master and > > slave virtio-net devices. =20 >=20 > I don't understand this comment. There is one virtio-net device and > one "virtio-bond" netdev. And user space has to be aware of the special > automatic arrangement anyway, because it can't touch the VF. It > doesn't make any difference whether it ignores the VF or PV and VF. > It simply can't touch the slaves, no matter how many there are. >=20 > > Also, from a user experience point of view, loading a virtio-net with > > BACKUP feature enabled will=C2=A0now show 2 virtio-net netdevs. =20 >=20 > One virtio-net and one virtio-bond, which represents what's happening. >=20 > > For live migration with advanced usecases that Siwei is suggesting, i=20 > > think we need a new driver with a new device type that can track the > > VF specific feature settings even when the VF driver is unloaded. =20 I see no added value of the 3 netdev model, there is no need for a bond device.