Jason Wang <jasowang@xxxxxxxxxx> writes: > On 05/22/2013 05:59 PM, Zang Hongyong wrote: >> On 2013/5/20 15:43, Michael S. Tsirkin wrote: >>> On Mon, May 20, 2013 at 02:11:19AM +0000, Qinchuanyu wrote: >>> Yes, I don't think we want to create threads even more aggressively >>> in all cases. I'm worried about scalability as it is. >>> I think we should explore a flexible approach, use a thread pool >>> (for example, a wq) to share threads between virtqueues, >>> switch to a separate thread only if there's free CPU and existing >>> threads are busy. Hopefully share threads between vhost instances too. >> On Xen platform, network backend pv driver model has evolved to this >> way. Netbacks from all DomUs share a thread pool, >> and thread number eaqual to cpu core number. >> Is there any plan for kvm paltform? > > There used to be two related RFCs for this, one is the multiple vhost > workers from Anthony another is percpu vhost thread from Shirley. You > can search the archives on netdev or kvm for the patches. As I've said to MST before, I think our entire model is wrong. Userspace should create the threads and call in. If you're doing kernel acceleration, two extra threads per NIC is a tiny overhead. Of course, such radical changes to vhost doesn't help existing users as Qinchuanyu asked... Cheers, Rusty, -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
