162306a36Sopenharmony_ci.. SPDX-License-Identifier: GPL-2.0 262306a36Sopenharmony_ci 362306a36Sopenharmony_ci=========================================== 462306a36Sopenharmony_ciHOWTO for multiqueue network device support 562306a36Sopenharmony_ci=========================================== 662306a36Sopenharmony_ci 762306a36Sopenharmony_ciSection 1: Base driver requirements for implementing multiqueue support 862306a36Sopenharmony_ci======================================================================= 962306a36Sopenharmony_ci 1062306a36Sopenharmony_ciIntro: Kernel support for multiqueue devices 1162306a36Sopenharmony_ci--------------------------------------------------------- 1262306a36Sopenharmony_ci 1362306a36Sopenharmony_ciKernel support for multiqueue devices is always present. 1462306a36Sopenharmony_ci 1562306a36Sopenharmony_ciBase drivers are required to use the new alloc_etherdev_mq() or 1662306a36Sopenharmony_cialloc_netdev_mq() functions to allocate the subqueues for the device. The 1762306a36Sopenharmony_ciunderlying kernel API will take care of the allocation and deallocation of 1862306a36Sopenharmony_cithe subqueue memory, as well as netdev configuration of where the queues 1962306a36Sopenharmony_ciexist in memory. 2062306a36Sopenharmony_ci 2162306a36Sopenharmony_ciThe base driver will also need to manage the queues as it does the global 2262306a36Sopenharmony_cinetdev->queue_lock today. Therefore base drivers should use the 2362306a36Sopenharmony_cinetif_{start|stop|wake}_subqueue() functions to manage each queue while the 2462306a36Sopenharmony_cidevice is still operational. netdev->queue_lock is still used when the device 2562306a36Sopenharmony_cicomes online or when it's completely shut down (unregister_netdev(), etc.). 2662306a36Sopenharmony_ci 2762306a36Sopenharmony_ci 2862306a36Sopenharmony_ciSection 2: Qdisc support for multiqueue devices 2962306a36Sopenharmony_ci=============================================== 3062306a36Sopenharmony_ci 3162306a36Sopenharmony_ciCurrently two qdiscs are optimized for multiqueue devices. The first is the 3262306a36Sopenharmony_cidefault pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue. 3362306a36Sopenharmony_ciA new round-robin qdisc, sch_multiq also supports multiple hardware queues. The 3462306a36Sopenharmony_ciqdisc is responsible for classifying the skb's and then directing the skb's to 3562306a36Sopenharmony_cibands and queues based on the value in skb->queue_mapping. Use this field in 3662306a36Sopenharmony_cithe base driver to determine which queue to send the skb to. 3762306a36Sopenharmony_ci 3862306a36Sopenharmony_cisch_multiq has been added for hardware that wishes to avoid head-of-line 3962306a36Sopenharmony_ciblocking. It will cycle though the bands and verify that the hardware queue 4062306a36Sopenharmony_ciassociated with the band is not stopped prior to dequeuing a packet. 4162306a36Sopenharmony_ci 4262306a36Sopenharmony_ciOn qdisc load, the number of bands is based on the number of queues on the 4362306a36Sopenharmony_cihardware. Once the association is made, any skb with skb->queue_mapping set, 4462306a36Sopenharmony_ciwill be queued to the band associated with the hardware queue. 4562306a36Sopenharmony_ci 4662306a36Sopenharmony_ci 4762306a36Sopenharmony_ciSection 3: Brief howto using MULTIQ for multiqueue devices 4862306a36Sopenharmony_ci========================================================== 4962306a36Sopenharmony_ci 5062306a36Sopenharmony_ciThe userspace command 'tc,' part of the iproute2 package, is used to configure 5162306a36Sopenharmony_ciqdiscs. To add the MULTIQ qdisc to your network device, assuming the device 5262306a36Sopenharmony_ciis called eth0, run the following command:: 5362306a36Sopenharmony_ci 5462306a36Sopenharmony_ci # tc qdisc add dev eth0 root handle 1: multiq 5562306a36Sopenharmony_ci 5662306a36Sopenharmony_ciThe qdisc will allocate the number of bands to equal the number of queues that 5762306a36Sopenharmony_cithe device reports, and bring the qdisc online. Assuming eth0 has 4 Tx 5862306a36Sopenharmony_ciqueues, the band mapping would look like:: 5962306a36Sopenharmony_ci 6062306a36Sopenharmony_ci band 0 => queue 0 6162306a36Sopenharmony_ci band 1 => queue 1 6262306a36Sopenharmony_ci band 2 => queue 2 6362306a36Sopenharmony_ci band 3 => queue 3 6462306a36Sopenharmony_ci 6562306a36Sopenharmony_ciTraffic will begin flowing through each queue based on either the simple_tx_hash 6662306a36Sopenharmony_cifunction or based on netdev->select_queue() if you have it defined. 6762306a36Sopenharmony_ci 6862306a36Sopenharmony_ciThe behavior of tc filters remains the same. However a new tc action, 6962306a36Sopenharmony_ciskbedit, has been added. Assuming you wanted to route all traffic to a 7062306a36Sopenharmony_cispecific host, for example 192.168.0.3, through a specific queue you could use 7162306a36Sopenharmony_cithis action and establish a filter such as:: 7262306a36Sopenharmony_ci 7362306a36Sopenharmony_ci tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ 7462306a36Sopenharmony_ci match ip dst 192.168.0.3 \ 7562306a36Sopenharmony_ci action skbedit queue_mapping 3 7662306a36Sopenharmony_ci 7762306a36Sopenharmony_ci:Author: Alexander Duyck <alexander.h.duyck@intel.com> 7862306a36Sopenharmony_ci:Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> 79