On 10/31/2012 03:05 AM, Rick Jones wrote:
On 10/30/2012 03:03 AM, Jason Wang wrote:
Hi all:

This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the
packets reception and transmission. Please review and comments.

Changes from v5:
- Align the implementation with the RFC spec update v4
- Switch the mode between single mode and multiqueue mode without reset
- Remove the 256 limitation of queues
- Use helpers to do the mapping between virtqueues and tx/rx queues
- Use commbined channels instead of separated rx/tx queus when do the queue
number configuartion
- Other coding style comments from Michael

Reference:
- A protype implementation of qemu-kvm support could by found in
git://github.com/jasowang/qemu-kvm-mq.git
- V5 could be found at http://lwn.net/Articles/505388/
- V4 could be found at https://lkml.org/lkml/2012/6/25/120
- V2 could be found at http://lwn.net/Articles/467283/
- Michael virtio-spec: http://www.spinics.net/lists/netdev/msg209986.html

Perf Numbers:

- Pktgen test shows the receiving capability of the multiqueue virtio-net were
   dramatically improved.
- Netperf result shows latency were greately improved according to the test
result.

I suppose it is technically correct to say that latency was improved, but usually for aggregate request/response tests I tend to talk about the aggregate transactions per second.

Sure.

Do you have a hypothesis as to why the improvement dropped going to 20 concurrent sessions from 10?

rick jones

I'm investigating this issuse currently, but with no much ideas. The aggregate transactions per second scales pretty well even with 20 cocurrent sessions when doing test between a local host and a local vm. Looks like some bottleneck were reached when doing testing over 10gb or vms as even if I increase the number of sessions, the result would not increase.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to