Thread (3 messages) 3 messages, 2 authors, 2018-06-27

Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2018-06-26 17:50:20
Also in: netdev, qemu-devel

Possibly related (same subject, not in this thread)

On Tue, Jun 26, 2018 at 05:08:13PM +0200, Cornelia Huck wrote:
On Fri, 22 Jun 2018 17:05:04 -0700
Siwei Liu [off-list ref] wrote:
quoted
On Fri, Jun 22, 2018 at 3:33 PM, Michael S. Tsirkin [off-list ref] wrote:
quoted
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.

-- 
MST
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help