From: Jason Wang <jasowang@redhat.com>
To: mst@redhat.com, akong@redhat.com, habanero@linux.vnet.ibm.com,
tahm@linux.vnet.ibm.com, haixiao@juniper.net,
jwhan@filewood.snu.ac.kr, ernesto.martin@viasat.com,
mashirle@us.ibm.com, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, krkumar2@in.ibm.com
Cc: shemminger@vyatta.com, edumazet@google.com,
Jason Wang <jasowang@redhat.com>
Subject: [net-next RFC V3 0/6] Multiqueue support in tun/tap
Date: Mon, 25 Jun 2012 19:59:17 +0800 [thread overview]
Message-ID: <1340625563-9300-1-git-send-email-jasowang@redhat.com> (raw)
In-Reply-To: <20120625060830.6765.27584.stgit@amd-6168-8-1.englab.nay.redhat.com>
Hello All:
This is an update of multiqueue support in tun/tap from V2. Please consider to
merge.
The main idea for this series is to let tun/tap device to benefit from
multiqueue network cards and multi-cores host by letting it to be able to
transmit and receive packets from mmultiple sockets/queues. This series allows
multiple sockets to be attached and detached to the tun/tap devices. Userspace
could utilize this parallism to achiveve higher throughput.
Some quick overview of the design:
- Moving socket from tun_device to tun_file.
- Allowing multiple sockets to be attached to a tun/tap devices.
- Using RCU to synchronize the data path and system call.
- A simple hash based queue selecting algorithm is used to choose the tx queue.
- Two new ioctls were added for the usespace to attach and detach socket to the device.
- ABI compatibility were maintained, userspace that only use one queue won't
need any changes.
Performance test:
This series were originally designed to serve as the backend of the multiqueue
virito-net in kvm guest. But the design is generic enough to let it to be reused
by any other type of userspace.
Since I would post a series of multiqueue virtio-net as RFC, so I would post the
performance result in that thread. To summarize the performance, the multiqueue
improves the transaction in the TCP_RR test but have some regression in small
packets transmission in TCP_STREAM test.
Martin test the multiqueue tap for their userspace, and he see an improvement in
terms of packets per second.
References:
- V2 of multiqueue tun/tap, http://lwn.net/Articles/459270/
- V1 of multiqueue tun/tap, http://www.mail-archive.com/kvm@vger.kernel.org/msg59479.html
Changes from V2:
- Rebase to the latest net-next
- Fix netdev leak when tun_attach fails
- Fix return value of TUNSETOWNER
- Purge the receive queue in socket destructor
- Enable multiqueue tun (V1 and V2 only allows mq to be eanbled for tap
- Add per-queue u64 statistics
- Fix wrong BUG_ON() check in tun_detach()
- Check numqueues instead of tfile[0] in tun_set_iff() to let tunctl -d works
correctly
- Set numqueues to MAX_TAP_QUEUES during tun_detach_all() to prevent the
attaching.
Changes from V1:
- Simplify the sockets array management by not leaving NULL in the slot.
- Optimization on the tx queue selecting.
- Fix the bug in tun_deatch_all()
Jason Wang (6):
tuntap: move socket to tun_file
tuntap: categorize ioctl
tuntap: introduce multiqueue flags
tuntap: multiqueue support
tuntap: per queue 64 bit stats
tuntap: add ioctls to attach or detach a file form tuntap device
drivers/net/tun.c | 797 ++++++++++++++++++++++++++++++------------------
include/linux/if_tun.h | 5 +
2 files changed, 503 insertions(+), 299 deletions(-)
next prev parent reply other threads:[~2012-06-25 12:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120625060830.6765.27584.stgit@amd-6168-8-1.englab.nay.redhat.com>
[not found] ` <20120625061018.6765.76633.stgit@amd-6168-8-1.englab.nay.redhat.com>
2012-06-25 8:25 ` [net-next RFC V3 PATCH 4/6] tuntap: multiqueue support Michael S. Tsirkin
2012-06-25 8:41 ` Michael S. Tsirkin
2012-06-26 3:42 ` Jason Wang
2012-06-26 10:42 ` Michael S. Tsirkin
2012-06-27 5:16 ` Jason Wang
2012-06-27 8:44 ` Michael S. Tsirkin
2012-06-28 3:02 ` Jason Wang
2012-06-28 4:52 ` Sridhar Samudrala
2012-06-28 5:31 ` Jason Wang
2012-06-26 5:52 ` Jason Wang
2012-06-26 11:54 ` Michael S. Tsirkin
2012-06-27 5:59 ` Jason Wang
2012-06-27 8:26 ` Michael S. Tsirkin
2012-06-28 3:15 ` Jason Wang
[not found] ` <20120625060945.6765.98618.stgit@amd-6168-8-1.englab.nay.redhat.com>
2012-06-25 8:27 ` [net-next RFC V3 PATCH 1/6] tuntap: move socket to tun_file Michael S. Tsirkin
2012-06-26 5:55 ` Jason Wang
2012-06-25 11:59 ` Jason Wang [this message]
2012-06-25 11:59 ` [PATCH " Jason Wang
2012-06-25 11:59 ` [PATCH 2/6] tuntap: categorize ioctl Jason Wang
2012-06-25 11:59 ` [PATCH 3/6] tuntap: introduce multiqueue flags Jason Wang
2012-06-25 11:59 ` [PATCH 4/6] tuntap: multiqueue support Jason Wang
2012-06-25 11:59 ` [PATCH 5/6] tuntap: per queue 64 bit stats Jason Wang
2012-06-25 12:52 ` Eric Dumazet
2012-06-26 6:00 ` Jason Wang
2012-06-26 6:10 ` Eric Dumazet
2012-06-26 6:28 ` Jason Wang
2012-06-26 19:46 ` [PATCH 5/6] tuntap: per queue 64 bit stats\ Michael S. Tsirkin
2012-06-25 11:59 ` [PATCH 6/6] tuntap: add ioctls to attach or detach a file form tuntap device Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1340625563-9300-1-git-send-email-jasowang@redhat.com \
--to=jasowang@redhat.com \
--cc=akong@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ernesto.martin@viasat.com \
--cc=habanero@linux.vnet.ibm.com \
--cc=haixiao@juniper.net \
--cc=jwhan@filewood.snu.ac.kr \
--cc=krkumar2@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mashirle@us.ibm.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=tahm@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®