From: "Michael S. Tsirkin" <mst@redhat.com> To: Stephen Hemminger <stephen@networkplumber.org> Cc: "Duyck, Alexander H" <alexander.h.duyck@intel.com>, virtio-dev@lists.oasis-open.org, Jiri Pirko <jiri@resnulli.us>, Jakub Kicinski <kubakici@wp.pl>, "Samudrala, Sridhar" <sridhar.samudrala@intel.com>, Alexander Duyck <alexander.duyck@gmail.com>, virtualization@lists.linux-foundation.org, Siwei Liu <loseweigh@gmail.com>, Netdev <netdev@vger.kernel.org>, David Miller <davem@davemloft.net> Subject: Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device Date: Tue, 27 Feb 2018 03:18:12 +0200 [thread overview] Message-ID: <20180227030424-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20180226170218.6b1dcf22@xeon-e3> On Mon, Feb 26, 2018 at 05:02:18PM -0800, Stephen Hemminger wrote: > On Mon, 26 Feb 2018 08:19:24 +0100 > Jiri Pirko <jiri@resnulli.us> wrote: > > > Sat, Feb 24, 2018 at 12:59:04AM CET, stephen@networkplumber.org wrote: > > >On Thu, 22 Feb 2018 13:30:12 -0800 > > >Alexander Duyck <alexander.duyck@gmail.com> wrote: > > > > > >> > Again, I undertand your motivation. Yet I don't like your solution. > > >> > But if the decision is made to do this in-driver bonding. I would like > > >> > to see it baing done some generic way: > > >> > 1) share the same "in-driver bonding core" code with netvsc > > >> > put to net/core. > > >> > 2) the "in-driver bonding core" will strictly limit the functionality, > > >> > like active-backup mode only, one vf, one backup, vf netdev type > > >> > check (so noone could enslave a tap or anything else) > > >> > If user would need something more, he should employ team/bond. > > > > > >Sharing would be good, but netvsc world would really like to only have > > >one visible network device. > > > > Why do you mind? All would be the same, there would be just another > > netdevice unused by the vm user (same as the vf netdev). > > > > I mind because our requirement is no changes to userspace. > No special udev rules, no bonding script, no setup. Agreed. It is mostly fine from this point of view, except that you need to know to skip the slaves. Maybe we could look at some kind of trick e.g. pretending link is down for slaves? > Things like cloudinit running on current distro's expect to see a single > eth0. The VF device show up can also be an issue because distro's have > stupid rules like Network Manager trying to start DHCP on every interface. > We deal with that now by doing stuff like udev rules to get it to stop > but that is still causing user errors. So the ideal of a single net device isn't achieved by netvsc. Since you have scripts to skip the PT device, can't they hind the PV slave too? How do they identify the device to skip? I agree it would be nice to have a way to hide the extra netdev from userspace. The benefit of the separation is that each slave device can be configured with e.g. its own native ethtool commands for optimum performance. -- MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Stephen Hemminger <stephen@networkplumber.org> Cc: Jiri Pirko <jiri@resnulli.us>, Alexander Duyck <alexander.duyck@gmail.com>, Jakub Kicinski <kubakici@wp.pl>, "Samudrala, Sridhar" <sridhar.samudrala@intel.com>, David Miller <davem@davemloft.net>, Netdev <netdev@vger.kernel.org>, virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, "Brandeburg, Jesse" <jesse.brandeburg@intel.com>, "Duyck, Alexander H" <alexander.h.duyck@intel.com>, Jason Wang <jasowang@redhat.com>, Siwei Liu <loseweigh@gmail.com> Subject: [virtio-dev] Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device Date: Tue, 27 Feb 2018 03:18:12 +0200 [thread overview] Message-ID: <20180227030424-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20180226170218.6b1dcf22@xeon-e3> On Mon, Feb 26, 2018 at 05:02:18PM -0800, Stephen Hemminger wrote: > On Mon, 26 Feb 2018 08:19:24 +0100 > Jiri Pirko <jiri@resnulli.us> wrote: > > > Sat, Feb 24, 2018 at 12:59:04AM CET, stephen@networkplumber.org wrote: > > >On Thu, 22 Feb 2018 13:30:12 -0800 > > >Alexander Duyck <alexander.duyck@gmail.com> wrote: > > > > > >> > Again, I undertand your motivation. Yet I don't like your solution. > > >> > But if the decision is made to do this in-driver bonding. I would like > > >> > to see it baing done some generic way: > > >> > 1) share the same "in-driver bonding core" code with netvsc > > >> > put to net/core. > > >> > 2) the "in-driver bonding core" will strictly limit the functionality, > > >> > like active-backup mode only, one vf, one backup, vf netdev type > > >> > check (so noone could enslave a tap or anything else) > > >> > If user would need something more, he should employ team/bond. > > > > > >Sharing would be good, but netvsc world would really like to only have > > >one visible network device. > > > > Why do you mind? All would be the same, there would be just another > > netdevice unused by the vm user (same as the vf netdev). > > > > I mind because our requirement is no changes to userspace. > No special udev rules, no bonding script, no setup. Agreed. It is mostly fine from this point of view, except that you need to know to skip the slaves. Maybe we could look at some kind of trick e.g. pretending link is down for slaves? > Things like cloudinit running on current distro's expect to see a single > eth0. The VF device show up can also be an issue because distro's have > stupid rules like Network Manager trying to start DHCP on every interface. > We deal with that now by doing stuff like udev rules to get it to stop > but that is still causing user errors. So the ideal of a single net device isn't achieved by netvsc. Since you have scripts to skip the PT device, can't they hind the PV slave too? How do they identify the device to skip? I agree it would be nice to have a way to hide the extra netdev from userspace. The benefit of the separation is that each slave device can be configured with e.g. its own native ethtool commands for optimum performance. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2018-02-27 1:18 UTC|newest] Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-16 18:11 [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device Sridhar Samudrala 2018-02-16 18:11 ` [virtio-dev] " Sridhar Samudrala 2018-02-16 18:11 ` [RFC PATCH v3 1/3] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit Sridhar Samudrala 2018-02-16 18:11 ` Sridhar Samudrala 2018-02-16 18:11 ` [virtio-dev] " Sridhar Samudrala 2018-02-16 18:11 ` [RFC PATCH v3 2/3] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala 2018-02-16 18:11 ` Sridhar Samudrala 2018-02-16 18:11 ` [virtio-dev] " Sridhar Samudrala 2018-02-17 3:04 ` Jakub Kicinski 2018-02-17 17:41 ` Alexander Duyck 2018-02-17 3:04 ` Jakub Kicinski 2018-02-16 18:11 ` [RFC PATCH v3 3/3] virtio_net: Enable alternate datapath without creating an additional netdev Sridhar Samudrala 2018-02-16 18:11 ` [virtio-dev] " Sridhar Samudrala 2018-02-16 18:11 ` Sridhar Samudrala 2018-02-17 2:38 ` [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device Jakub Kicinski 2018-02-17 2:38 ` Jakub Kicinski 2018-02-17 17:12 ` Alexander Duyck 2018-02-17 17:12 ` [virtio-dev] " Alexander Duyck 2018-02-19 6:11 ` Jakub Kicinski 2018-02-20 16:26 ` Samudrala, Sridhar 2018-02-20 16:26 ` [virtio-dev] " Samudrala, Sridhar 2018-02-20 16:26 ` Samudrala, Sridhar 2018-02-21 23:50 ` Siwei Liu 2018-02-21 23:50 ` [virtio-dev] " Siwei Liu 2018-02-22 0:17 ` Alexander Duyck 2018-02-22 0:17 ` Alexander Duyck 2018-02-22 0:17 ` [virtio-dev] " Alexander Duyck 2018-02-22 1:59 ` Siwei Liu 2018-02-22 1:59 ` Siwei Liu 2018-02-22 1:59 ` [virtio-dev] " Siwei Liu 2018-02-22 2:35 ` Samudrala, Sridhar 2018-02-22 2:35 ` Samudrala, Sridhar 2018-02-22 2:35 ` [virtio-dev] " Samudrala, Sridhar 2018-02-22 3:28 ` Samudrala, Sridhar 2018-02-22 3:28 ` [virtio-dev] " Samudrala, Sridhar 2018-02-23 22:22 ` Siwei Liu 2018-02-23 22:22 ` [virtio-dev] " Siwei Liu 2018-02-23 22:38 ` Jiri Pirko 2018-02-24 0:17 ` Siwei Liu 2018-02-24 0:17 ` [virtio-dev] " Siwei Liu 2018-02-24 0:03 ` Stephen Hemminger 2018-02-25 22:17 ` Alexander Duyck 2018-02-25 22:17 ` [virtio-dev] " Alexander Duyck 2018-02-25 22:17 ` Alexander Duyck 2018-02-21 23:50 ` Siwei Liu 2018-02-17 17:12 ` Alexander Duyck 2018-02-20 10:42 ` Jiri Pirko 2018-02-20 16:04 ` Alexander Duyck 2018-02-20 16:04 ` [virtio-dev] " Alexander Duyck 2018-02-20 16:29 ` Jiri Pirko 2018-02-20 17:14 ` Samudrala, Sridhar 2018-02-20 17:14 ` [virtio-dev] " Samudrala, Sridhar 2018-02-20 20:14 ` Jiri Pirko 2018-02-20 21:02 ` Alexander Duyck 2018-02-20 21:02 ` [virtio-dev] " Alexander Duyck 2018-02-20 21:02 ` Alexander Duyck 2018-02-20 22:33 ` Jakub Kicinski 2018-02-21 9:51 ` Jiri Pirko 2018-02-21 15:56 ` Alexander Duyck 2018-02-21 15:56 ` [virtio-dev] " Alexander Duyck 2018-02-21 16:11 ` Jiri Pirko 2018-02-21 16:49 ` Alexander Duyck 2018-02-21 16:49 ` [virtio-dev] " Alexander Duyck 2018-02-21 16:58 ` Jiri Pirko 2018-02-21 17:56 ` Alexander Duyck 2018-02-21 17:56 ` Alexander Duyck 2018-02-21 17:56 ` [virtio-dev] " Alexander Duyck 2018-02-21 19:38 ` Jiri Pirko 2018-02-21 20:57 ` Alexander Duyck 2018-02-21 20:57 ` [virtio-dev] " Alexander Duyck 2018-02-22 2:02 ` Jakub Kicinski 2018-02-22 2:15 ` Samudrala, Sridhar 2018-02-22 2:15 ` [virtio-dev] " Samudrala, Sridhar 2018-02-22 2:15 ` Samudrala, Sridhar 2018-02-22 8:11 ` Jiri Pirko 2018-02-22 11:54 ` Or Gerlitz 2018-02-22 13:07 ` Jiri Pirko 2018-02-22 15:30 ` Alexander Duyck 2018-02-22 15:30 ` [virtio-dev] " Alexander Duyck 2018-02-22 21:30 ` Alexander Duyck 2018-02-22 21:30 ` [virtio-dev] " Alexander Duyck 2018-02-23 23:59 ` Stephen Hemminger 2018-02-25 22:21 ` Alexander Duyck 2018-02-25 22:21 ` Alexander Duyck 2018-02-25 22:21 ` [virtio-dev] " Alexander Duyck 2018-02-26 7:19 ` Jiri Pirko 2018-02-27 1:02 ` Stephen Hemminger 2018-02-27 1:18 ` Michael S. Tsirkin [this message] 2018-02-27 1:18 ` [virtio-dev] " Michael S. Tsirkin 2018-02-27 8:27 ` Jiri Pirko 2018-02-22 21:30 ` Alexander Duyck 2018-02-21 20:57 ` Alexander Duyck 2018-02-21 16:49 ` Alexander Duyck 2018-02-21 15:56 ` Alexander Duyck 2018-02-20 17:14 ` Samudrala, Sridhar 2018-02-20 17:23 ` Alexander Duyck 2018-02-20 17:23 ` [virtio-dev] " Alexander Duyck 2018-02-20 19:53 ` Jiri Pirko 2018-02-27 8:49 ` Jiri Pirko 2018-02-27 21:16 ` Alexander Duyck 2018-02-27 21:16 ` Alexander Duyck 2018-02-27 21:16 ` [virtio-dev] " Alexander Duyck 2018-02-27 21:23 ` Michael S. Tsirkin 2018-02-27 21:23 ` [virtio-dev] " Michael S. Tsirkin 2018-02-27 21:41 ` Jakub Kicinski 2018-02-28 7:08 ` Jiri Pirko 2018-02-28 14:32 ` Michael S. Tsirkin 2018-02-28 14:32 ` [virtio-dev] " Michael S. Tsirkin 2018-02-28 15:11 ` Jiri Pirko 2018-02-28 15:45 ` Michael S. Tsirkin 2018-02-28 15:45 ` Michael S. Tsirkin 2018-02-28 15:45 ` [virtio-dev] " Michael S. Tsirkin 2018-02-28 19:25 ` Jiri Pirko 2018-02-28 20:48 ` Michael S. Tsirkin 2018-02-28 20:48 ` Michael S. Tsirkin 2018-02-28 20:48 ` [virtio-dev] " Michael S. Tsirkin 2018-02-27 21:30 ` Michael S. Tsirkin 2018-02-27 21:30 ` [virtio-dev] " Michael S. Tsirkin 2018-02-27 21:30 ` Michael S. Tsirkin 2018-02-20 16:04 ` Alexander Duyck 2018-02-16 18:11 Sridhar Samudrala
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180227030424-mutt-send-email-mst@kernel.org \ --to=mst@redhat.com \ --cc=alexander.duyck@gmail.com \ --cc=alexander.h.duyck@intel.com \ --cc=davem@davemloft.net \ --cc=jiri@resnulli.us \ --cc=kubakici@wp.pl \ --cc=loseweigh@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=sridhar.samudrala@intel.com \ --cc=stephen@networkplumber.org \ --cc=virtio-dev@lists.oasis-open.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.