search for: divereg

Displaying 6 results from an estimated 6 matches for "divereg".

Did you mean: diverge
2018 Jun 23
2
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
...; >> That's what I said "to keep the potential to support both" models. But >> we should not go further along to assume the other aspect ie. to get >> PV accelerated whenever possible, but not to get VF migrated whenever >> possible. That's essetially a big diveregence of the priority for the >> goal we'd want to pursue. >> >> -Siwei > > 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 tha...
2018 Jun 22
2
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
...ng as we can hide the lower devices. That's what I said "to keep the potential to support both" models. But we should not go further along to assume the other aspect ie. to get PV accelerated whenever possible, but not to get VF migrated whenever possible. That's essetially a big diveregence of the priority for the goal we'd want to pursue. -Siwei > > Anything else isn't well supported and I'm not sure we > should complicate code too much to support it. > >> >> > >> >> What about migration of vfio devices that are not easily repl...
2018 Jun 26
1
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Tue, Jun 26, 2018 at 05:08:13PM +0200, Cornelia Huck wrote: > On Fri, 22 Jun 2018 17:05:04 -0700 > Siwei Liu <loseweigh at gmail.com> wrote: > > > On Fri, Jun 22, 2018 at 3:33 PM, Michael S. Tsirkin <mst at 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 me...
2018 Jun 22
0
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
...er devices. > > That's what I said "to keep the potential to support both" models. But > we should not go further along to assume the other aspect ie. to get > PV accelerated whenever possible, but not to get VF migrated whenever > possible. That's essetially a big diveregence of the priority for the > goal we'd want to pursue. > > -Siwei 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. Rephrasing requirements in terms of acceleration actually made things...
2018 Jun 26
0
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Fri, 22 Jun 2018 17:05:04 -0700 Siwei Liu <loseweigh at gmail.com> wrote: > On Fri, Jun 22, 2018 at 3:33 PM, Michael S. Tsirkin <mst at 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, latenc...
2018 Jun 22
2
[virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Fri, Jun 22, 2018 at 12:05 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Fri, Jun 22, 2018 at 05:09:55PM +0200, Cornelia Huck wrote: >> On Thu, 21 Jun 2018 21:20:13 +0300 >> "Michael S. Tsirkin" <mst at redhat.com> wrote: >> >> > On Thu, Jun 21, 2018 at 04:59:13PM +0200, Cornelia Huck wrote: >> > > OK, so what about the