From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amritha Nambiar Subject: [net-next PATCH v2 4/4] Documentation: Add explanation for XPS using Rx-queue map Date: Tue, 15 May 2018 18:27:00 -0700 Message-ID: <152643402028.4991.17827999890762944370.stgit@anamdev.jf.intel.com> References: <152643356116.4991.7215767041139726872.stgit@anamdev.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: alexander.h.duyck@intel.com, amritha.nambiar@intel.com, sridhar.samudrala@intel.com, edumazet@google.com, hannes@stressinduktion.org, tom@herbertland.com To: netdev@vger.kernel.org, davem@davemloft.net Return-path: Received: from mga07.intel.com ([134.134.136.100]:2550 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752321AbeEPBa3 (ORCPT ); Tue, 15 May 2018 21:30:29 -0400 In-Reply-To: <152643356116.4991.7215767041139726872.stgit@anamdev.jf.intel.com> Sender: netdev-owner@vger.kernel.org List-ID: Signed-off-by: Amritha Nambiar --- Documentation/networking/scaling.txt | 58 ++++++++++++++++++++++++++++------ 1 file changed, 48 insertions(+), 10 deletions(-) diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt index f55639d..834147c 100644 --- a/Documentation/networking/scaling.txt +++ b/Documentation/networking/scaling.txt @@ -366,8 +366,13 @@ XPS: Transmit Packet Steering Transmit Packet Steering is a mechanism for intelligently selecting which transmit queue to use when transmitting a packet on a multi-queue -device. To accomplish this, a mapping from CPU to hardware queue(s) is -recorded. The goal of this mapping is usually to assign queues +device. This can be accomplished by recording two kinds of maps, either +a mapping of CPU to hardware queue(s) or a mapping of receive queue(s) +to hardware transmit queue(s). + +1. XPS using CPUs map + +The goal of this mapping is usually to assign queues exclusively to a subset of CPUs, where the transmit completions for these queues are processed on a CPU within this set. This choice provides two benefits. First, contention on the device queue lock is @@ -377,12 +382,36 @@ transmit queue). Secondly, cache miss rate on transmit completion is reduced, in particular for data cache lines that hold the sk_buff structures. -XPS is configured per transmit queue by setting a bitmap of CPUs that -may use that queue to transmit. The reverse mapping, from CPUs to -transmit queues, is computed and maintained for each network device. -When transmitting the first packet in a flow, the function -get_xps_queue() is called to select a queue. This function uses the ID -of the running CPU as a key into the CPU-to-queue lookup table. If the +2. XPS using receive queues map + +This mapping is used to pick transmit queue based on the receive +queue(s) map configuration set by the administrator. A set of receive +queues can be mapped to a set of transmit queues (many:many), although +the common use case is a 1:1 mapping. This will enable sending packets +on the same queue pair for transmit and receive. This is useful for +busy polling multi-threaded workloads where there are challenges in +associating a given CPU to a given application thread. The application +threads are not pinned to CPUs and each thread handles packets +received on a single queue. The receive queue number is cached in the +socket for the connection and there is no need for adding flow entries +as in the case of aRFS or flow director. In this model, sending the +packets on the same transmit queue corresponding to the queue-pair +associated with the receive queue has benefits in keeping the CPU overhead +low. Transmit completion work is locked into the same queue pair that +a given application is polling on. This avoids the overhead of triggering +an interrupt on another CPU. When the application cleans up the packets +during the busy poll, transmit completion may be processed along with it +in the same thread context and so result in reduced latency. + +XPS is configured per transmit queue by setting a bitmap of +CPUs/receive-queues that may use that queue to transmit. The reverse +mapping, from CPUs to transmit queues or from receive-queues to transmit +queues, is computed and maintained for each network device. When +transmitting the first packet in a flow, the function get_xps_queue() is +called to select a queue. This function uses the ID of the receive queue +for the socket connection for a match in the receive queue-to-transmit queue +lookup table. Alternatively, this function can also use the ID of the +running CPU as a key into the CPU-to-queue lookup table. If the ID matches a single queue, that is used for transmission. If multiple queues match, one is selected by using the flow hash to compute an index into the set. @@ -404,11 +433,15 @@ acknowledged. XPS is only available if the kconfig symbol CONFIG_XPS is enabled (on by default for SMP). The functionality remains disabled until explicitly -configured. To enable XPS, the bitmap of CPUs that may use a transmit -queue is configured using the sysfs file entry: +configured. To enable XPS, the bitmap of CPUs/receive-queues that may +use a transmit queue is configured using the sysfs file entry: +For selection based on CPUs map: /sys/class/net//queues/tx-/xps_cpus +For selection based on receive-queues map: +/sys/class/net//queues/tx-/xps_rxqs + == Suggested Configuration For a network device with a single transmission queue, XPS configuration @@ -421,6 +454,11 @@ best CPUs to share a given queue are probably those that share the cache with the CPU that processes transmit completions for that queue (transmit interrupts). +For transmit queue selection based on receive queue(s), XPS has to be +explicitly configured mapping receive-queue(s) to transmit queue(s). If the +user configuration for receive-queue map does not apply, then the transmit +queue is selected based on the CPUs map. + Per TX Queue rate limitation: =============================