Return to multiqueue.txt CVS log

Up to [Development] / linux-2.6-xfs / Documentation / networking

Update 2.6.x-xfs to 2.6.23-rc4.

Also update fs/xfs with external mainline changes.
There were 12 such missing commits that I detected:

--------
commit ad690ef9e690f6c31f7d310b09ef1314bcec9033
Author: Al Viro <viro@ftp.linux.org.uk>
    xfs ioctl __user annotations

commit 20c2df83d25c6a95affe6157a4c9cac4cf5ffaac
Author: Paul Mundt <lethal@linux-sh.org>
    mm: Remove slab destructors from kmem_cache_create().

commit d0217ac04ca6591841e5665f518e38064f4e65bd
Author: Nick Piggin <npiggin@suse.de>
    mm: fault feedback #1

commit 54cb8821de07f2ffcd28c380ce9b93d5784b40d7
Author: Nick Piggin <npiggin@suse.de>
    mm: merge populate and nopage into fault (fixes nonlinear)

commit d00806b183152af6d24f46f0c33f14162ca1262a
Author: Nick Piggin <npiggin@suse.de>
    mm: fix fault vs invalidate race for linear mappings

commit a569425512253992cc64ebf8b6d00a62f986db3e
Author: Christoph Hellwig <hch@infradead.org>
    knfsd: exportfs: add exportfs.h header

commit 831441862956fffa17b9801db37e6ea1650b0f69
Author: Rafael J. Wysocki <rjw@sisk.pl>
    Freezer: make kernel threads nonfreezable by default

commit 8e1f936b73150f5095448a0fee6d4f30a1f9001d
Author: Rusty Russell <rusty@rustcorp.com.au>
    mm: clean up and kernelify shrinker registration

commit 5ffc4ef45b3b0a57872f631b4e4ceb8ace0d7496
Author: Jens Axboe <jens.axboe@oracle.com>
    sendfile: remove .sendfile from filesystems that use generic_file_sendfile()

commit 8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d
Author: Rafael J. Wysocki <rjw@sisk.pl>
    Add suspend-related notifications for CPU hotplug

commit 59c51591a0ac7568824f541f57de967e88adaa07
Author: Michael Opdenacker <michael@free-electrons.com>
    Fix occurrences of "the the "

commit 0ceb331433e8aad9c5f441a965d7c681f8b9046f
Author: Dmitriy Monakhov <dmonakhov@openvz.org>
    mm: move common segment checks to separate helper function
--------
Merge of 2.6.x-xfs-melb:linux:29656b by kenmcd.

		HOWTO for multiqueue network device support
		===========================================

Section 1: Base driver requirements for implementing multiqueue support
Section 2: Qdisc support for multiqueue devices
Section 3: Brief howto using PRIO or RR for multiqueue devices


Intro: Kernel support for multiqueue devices
---------------------------------------------------------

Kernel support for multiqueue devices is only an API that is presented to the
netdevice layer for base drivers to implement.  This feature is part of the
core networking stack, and all network devices will be running on the
multiqueue-aware stack.  If a base driver only has one queue, then these
changes are transparent to that driver.


Section 1: Base driver requirements for implementing multiqueue support
-----------------------------------------------------------------------

Base drivers are required to use the new alloc_etherdev_mq() or
alloc_netdev_mq() functions to allocate the subqueues for the device.  The
underlying kernel API will take care of the allocation and deallocation of
the subqueue memory, as well as netdev configuration of where the queues
exist in memory.

The base driver will also need to manage the queues as it does the global
netdev->queue_lock today.  Therefore base drivers should use the
netif_{start|stop|wake}_subqueue() functions to manage each queue while the
device is still operational.  netdev->queue_lock is still used when the device
comes online or when it's completely shut down (unregister_netdev(), etc.).

Finally, the base driver should indicate that it is a multiqueue device.  The
feature flag NETIF_F_MULTI_QUEUE should be added to the netdev->features
bitmap on device initialization.  Below is an example from e1000:

#ifdef CONFIG_E1000_MQ
	if ( (adapter->hw.mac.type == e1000_82571) ||
	     (adapter->hw.mac.type == e1000_82572) ||
	     (adapter->hw.mac.type == e1000_80003es2lan))
		netdev->features |= NETIF_F_MULTI_QUEUE;
#endif


Section 2: Qdisc support for multiqueue devices
-----------------------------------------------

Currently two qdiscs support multiqueue devices.  A new round-robin qdisc,
sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to
bands and queues, and will store the queue mapping into skb->queue_mapping.
Use this field in the base driver to determine which queue to send the skb
to.

sch_rr has been added for hardware that doesn't want scheduling policies from
software, so it's a straight round-robin qdisc.  It uses the same syntax and
classification priomap that sch_prio uses, so it should be intuitive to
configure for people who've used sch_prio.

The PRIO qdisc naturally plugs into a multiqueue device.  If PRIO has been
built with NET_SCH_PRIO_MQ, then upon load, it will make sure the number of
bands requested is equal to the number of queues on the hardware.  If they
are equal, it sets a one-to-one mapping up between the queues and bands.  If
they're not equal, it will not load the qdisc.  This is the same behavior
for RR.  Once the association is made, any skb that is classified will have
skb->queue_mapping set, which will allow the driver to properly queue skb's
to multiple queues.


Section 3: Brief howto using PRIO and RR for multiqueue devices
---------------------------------------------------------------

The userspace command 'tc,' part of the iproute2 package, is used to configure
qdiscs.  To add the PRIO qdisc to your network device, assuming the device is
called eth0, run the following command:

# tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue

This will create 4 bands, 0 being highest priority, and associate those bands
to the queues on your NIC.  Assuming eth0 has 4 Tx queues, the band mapping
would look like:

band 0 => queue 0
band 1 => queue 1
band 2 => queue 2
band 3 => queue 3

Traffic will begin flowing through each queue if your TOS values are assigning
traffic across the various bands.  For example, ssh traffic will always try to
go out band 0 based on TOS -> Linux priority conversion (realtime traffic),
so it will be sent out queue 0.  ICMP traffic (pings) fall into the "normal"
traffic classification, which is band 1.  Therefore pings will be send out
queue 1 on the NIC.

Note the use of the multiqueue keyword.  This is only in versions of iproute2
that support multiqueue networking devices; if this is omitted when loading
a qdisc onto a multiqueue device, the qdisc will load and operate the same
if it were loaded onto a single-queue device (i.e. - sends all traffic to
queue 0).

Another alternative to multiqueue band allocation can be done by using the
multiqueue option and specify 0 bands.  If this is the case, the qdisc will
allocate the number of bands to equal the number of queues that the device
reports, and bring the qdisc online.

The behavior of tc filters remains the same, where it will override TOS priority
classification.


Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>