mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2024-12-28 16:52:18 +00:00
docs: networking: convert multiqueue.txt to ReST
- add SPDX header; - adjust titles and chapters, adding proper markups; - mark code blocks and literals as such; - use :field: markup; - adjust identation, whitespaces and blank lines; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
e14fd64dcd
commit
e98aa68223
@ -1639,7 +1639,7 @@ can safely be sent over either interface. Such configurations may be achieved
|
||||
using the traffic control utilities inherent in linux.
|
||||
|
||||
By default the bonding driver is multiqueue aware and 16 queues are created
|
||||
when the driver initializes (see Documentation/networking/multiqueue.txt
|
||||
when the driver initializes (see Documentation/networking/multiqueue.rst
|
||||
for details). If more or less queues are desired the module parameter
|
||||
tx_queues can be used to change this value. There is no sysfs parameter
|
||||
available as the allocation is done at module init time.
|
||||
|
@ -79,6 +79,7 @@ Contents:
|
||||
ltpc
|
||||
mac80211-injection
|
||||
mpls-sysctl
|
||||
multiqueue
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
@ -1,17 +1,17 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
HOWTO for multiqueue network device support
|
||||
===========================================
|
||||
===========================================
|
||||
HOWTO for multiqueue network device support
|
||||
===========================================
|
||||
|
||||
Section 1: Base driver requirements for implementing multiqueue support
|
||||
=======================================================================
|
||||
|
||||
Intro: Kernel support for multiqueue devices
|
||||
---------------------------------------------------------
|
||||
|
||||
Kernel support for multiqueue devices is always present.
|
||||
|
||||
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
|
||||
@ -26,8 +26,7 @@ comes online or when it's completely shut down (unregister_netdev(), etc.).
|
||||
|
||||
|
||||
Section 2: Qdisc support for multiqueue devices
|
||||
|
||||
-----------------------------------------------
|
||||
===============================================
|
||||
|
||||
Currently two qdiscs are optimized for multiqueue devices. The first is the
|
||||
default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue.
|
||||
@ -46,22 +45,22 @@ will be queued to the band associated with the hardware queue.
|
||||
|
||||
|
||||
Section 3: Brief howto using MULTIQ for multiqueue devices
|
||||
---------------------------------------------------------------
|
||||
==========================================================
|
||||
|
||||
The userspace command 'tc,' part of the iproute2 package, is used to configure
|
||||
qdiscs. To add the MULTIQ qdisc to your network device, assuming the device
|
||||
is called eth0, run the following command:
|
||||
is called eth0, run the following command::
|
||||
|
||||
# tc qdisc add dev eth0 root handle 1: multiq
|
||||
# tc qdisc add dev eth0 root handle 1: multiq
|
||||
|
||||
The qdisc will allocate the number of bands to equal the number of queues that
|
||||
the device reports, and bring the qdisc online. Assuming eth0 has 4 Tx
|
||||
queues, the band mapping would look like:
|
||||
queues, the band mapping would look like::
|
||||
|
||||
band 0 => queue 0
|
||||
band 1 => queue 1
|
||||
band 2 => queue 2
|
||||
band 3 => queue 3
|
||||
band 0 => queue 0
|
||||
band 1 => queue 1
|
||||
band 2 => queue 2
|
||||
band 3 => queue 3
|
||||
|
||||
Traffic will begin flowing through each queue based on either the simple_tx_hash
|
||||
function or based on netdev->select_queue() if you have it defined.
|
||||
@ -69,11 +68,11 @@ function or based on netdev->select_queue() if you have it defined.
|
||||
The behavior of tc filters remains the same. However a new tc action,
|
||||
skbedit, has been added. Assuming you wanted to route all traffic to a
|
||||
specific host, for example 192.168.0.3, through a specific queue you could use
|
||||
this action and establish a filter such as:
|
||||
this action and establish a filter such as::
|
||||
|
||||
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
|
||||
match ip dst 192.168.0.3 \
|
||||
action skbedit queue_mapping 3
|
||||
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
|
||||
match ip dst 192.168.0.3 \
|
||||
action skbedit queue_mapping 3
|
||||
|
||||
Author: Alexander Duyck <alexander.h.duyck@intel.com>
|
||||
Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
|
||||
:Author: Alexander Duyck <alexander.h.duyck@intel.com>
|
||||
:Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
|
Loading…
Reference in New Issue
Block a user