Re: [net-next RFC V5 3/5] virtio: intorduce an API to set affinity for a virtqueue
Il 29/07/2012 22:40, Michael S. Tsirkin ha scritto: Did you set the affinity manually in your experiments, or perhaps there is a difference between scsi and networking... (interrupt mitigation?) You need to run irqbalancer in guest to make it actually work. Do you? Yes, of course, now on to debugging that one. I just wanted to ask before the weekend if I was missing something as obvious as that. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
Il 30/07/2012 06:43, Asias He ha scritto: Yes. Something like this: qemu -drive file=foo.img,cache=writeback/unsafe is not safe against power losses also? cache=writeback and cache=none are safe, cache=unsafe isn't. I think we can add REQ_FLUSH REQ_FUA support to bio path and that deserves another patch. You only need to add REQ_FLUSH support. The virtio-blk protocol does not support REQ_FUA, because there's no easy way to do it in userspace. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [net-next RFC V5 4/5] virtio_net: multiqueue support
On 07/29/2012 11:44 AM, Michael S. Tsirkin wrote: On Sat, Jul 21, 2012 at 02:02:58PM +0200, Sasha Levin wrote: On 07/20/2012 03:40 PM, Michael S. Tsirkin wrote: - err = init_vqs(vi); + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) + vi-has_cvq = true; + How about we disable multiqueue if there's no cvq? Will make logic a bit simpler, won't it? multiqueues don't really depend on cvq. Does this added complexity really justifies adding an artificial limit? Well !cvq support is a legacy feature: the reason we support it in driver is to avoid breaking on old hosts. Adding more code to that path just doesn't make much sense since old hosts won't have mq. Is it really a legacy feature? The spec suggests that its an optional queue which is not necessary for the operation of the device. Which is why we never implemented it in lkvm - we weren't interested in any of the features it provided at that time and we could provide high performance with vhost support even without it. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
On Mon, Jul 30, 2012 at 09:31:06AM +0200, Paolo Bonzini wrote: You only need to add REQ_FLUSH support. The virtio-blk protocol does not support REQ_FUA, because there's no easy way to do it in userspace. A bio-based driver needs to handle both REQ_FLUSH and REQ_FUA as it does not get the sequencing of REQ_FUA into REQ_FLUSH that request based drivers can request. To what the REQ_FUA request gets translated is a different story. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
On Mon, Jul 30, 2012 at 12:43:12PM +0800, Asias He wrote: I think we can add REQ_FLUSH REQ_FUA support to bio path and that deserves another patch. Adding it is a requirement for merging the code. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
