Message-Id: <1340625563-9300-1-git-send-email-jasowang@redhat.com>
Date:	Mon, 25 Jun 2012 19:59:17 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	mst@...hat.com, akong@...hat.com, habanero@...ux.vnet.ibm.com,
	tahm@...ux.vnet.ibm.com, haixiao@...iper.net,
	jwhan@...ewood.snu.ac.kr, ernesto.martin@...sat.com,
	mashirle@...ibm.com, davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, krkumar2@...ibm.com
Cc:	shemminger@...tta.com, edumazet@...gle.com,
	Jason Wang <jasowang@...hat.com>
Subject: [net-next RFC V3 0/6] Multiqueue support in tun/tap

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(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists