jason wang <jasowang@xxxxxxxxxx> wrote on 11/16/2011 11:40:45 AM: Hi Jason, > Have any thought in mind to solve the issue of flow handling? So far nothing concrete. > Maybe some performance numbers first is better, it would let us know > where we are. During the test of my patchset, I find big regression of > small packet transmission, and more retransmissions were noticed. This > maybe also the issue of flow affinity. One interesting things is to see > whether this happens in your patches :) I haven't got any results for small packet, but will run this week and send an update. I remember my earlier patches having regression for small packets. > I've played with a basic flow director implementation based on my series > which want to make sure the packets of a flow was handled by the same > vhost thread/guest vcpu. This is done by: > > - bind virtqueue to guest cpu > - record the hash to queue mapping when guest sending packets and use > this mapping to choose the virtqueue when forwarding packets to guest > > Test shows some help during for receiving packets from external host and > packet sending to local host. But it would hurt the performance of > sending packets to remote host. This is not the perfect solution as it > can not handle guest moving processes among vcpus, I plan to try > accelerate RFS and sharing the mapping between host and guest. > > Anyway this is just for receiving, the small packet sending need more > thoughts. I don't recollect small packet performance for guest->local host. Also, using multiple tuns devices on the bridge (instead of mq-tun) balances the rx/tx of a flow to a single vq. Then you can avoid mq-tun with it's queue selector function, etc. Have you tried it? I will run my tests this week and get back. thanks, - KK -- 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
