On Tue, 26 Jun 2018 20:50:20 +0300 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Tue, Jun 26, 2018 at 05:08:13PM +0200, Cornelia Huck wrote: > > On Fri, 22 Jun 2018 17:05:04 -0700 > > Siwei Liu <losewe...@gmail.com> wrote: > > > > > On Fri, Jun 22, 2018 at 3:33 PM, Michael S. Tsirkin <m...@redhat.com> > > > wrote: > > > > I suspect the diveregence will be lost on most users though > > > > simply because they don't even care about vfio. They just > > > > want things to go fast. > > > > > > Like Jason said, VF isn't faster than virtio-net in all cases. It > > > depends on the workload and performance metrics: throughput, latency, > > > or packet per second. > > > > So, will it be guest/admin-controllable then where the traffic flows > > through? Just because we do have a vf available after negotiation of > > the feature bit, it does not necessarily mean we want to use it? Do we > > (the guest) even want to make it visible in that case? > > I think these ideas belong to what Alex Duyck wanted to do: > some kind of advanced device that isn't tied to > any network interfaces and allows workload and performance > specific tuning. > > Way out of scope for a simple failover, and more importantly, > no one is looking at even enumerating the problems involved, > much less solving them. So, for simplicity's sake, we need to rely on the host admin configuring the vm for its guest's intended use case. Sounds fair, but probably needs a note somewhere. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
