--- title: "More NIC Receive Queues Do Not Create More Network Ports" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/nic-rss-receive-queues-versus-port-capacity" last-updated: "2026-10-20" --- # More NIC Receive Queues Do Not Create More Network Ports Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Multiple NIC receive queues can distribute host receive-processing work across CPU contexts. They do not add external ports, multiply a link's rate or establish an SR-IOV allocation. In the conventional RSS model examined here, a stable packet-header hash and indirection mapping select one receive queue for a flow. More queues therefore provide an opportunity for parallel processing across flows, rather than a promise that one flow uses every queue. ## Keep ports, functions and receive queues in separate fields A supplier's queue count needs a unit and an attachment point. Ask whether it describes hardware receive queues available to the offered host interface, a device-wide maximum or resources shared with other allocations. A maximum feature count leaves the actual purchase unresolved. A physical network port identifies an external attachment. A PCIe function identifies a device interface. Linux 6.18's SR-IOV overview explains that a VF has its own PCI configuration identity and register space. Multiple receive queues do not, by themselves, establish multiple VFs. Conversely, a function count does not specify its receive queues or physical connections. Obtain the actual mapping; a PF label supplies no universal one-function-to-one-port rule. Receive descriptor queues organize the NIC's receive work for host processing. Microsoft's hardware-queuing explanation describes received buffers assigned to queues associated with CPUs. These are resources along the receive path, rather than additional cable endpoints. The CPU resources that perform that work are another part of the description: queue availability alone supplies neither an exclusive CPU allocation nor a measured processing rate. The linked SR-IOV article examines function allocations and shared physical dependencies. This comparison asks whether the offered receive path can distribute the host's processing work. References: [K2](https://docs.kernel.org/6.18/PCI/pci-iov-howto.html), [M2](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-with-hardware-queuing) ## Follow the hash, indirection entry and queue Linux 6.18 describes conventional receive-side scaling, or RSS, as header-based classification into receive queues. A packet hash selects an indirection-table entry containing a queue number. Queue interrupt associations provide a route to CPU processing. This explains how different packet streams can reach different processing contexts. For this comparison, a flow means a packet stream whose relevant hash inputs remain unchanged. Stipulate a fixed hash and indirection mapping. Its packets then select the same queue. Two different hash values can also resolve to the same queue: the table's entries need not name different destinations. Microsoft's RSS introduction, updated November 5, 2025, distinguishes hardware support levels, including hash calculation with a single receive queue and implementations with multiple hardware receive queues. Its Windows driver architecture is separate from the Linux model. An RSS feature label therefore needs the offered hardware and driver implementation behind it; do not assume every NIC classifies every traffic type identically. The selection chain identifies where receive work can be distributed. It does not itself say how much work arrives, whether the application can consume it concurrently or whether those CPU resources have spare processing capacity. References: [K1](https://docs.kernel.org/6.18/networking/scaling.html), [M1](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling) ## Assign six fictional flows to four receive queues Consider a fictional host interface with four available receive queues numbered 0 through 3. Its sole external link is stipulated to operate at 100 Gb/s. Six distinct incoming flows, F1 through F6, have fixed classifications and the following invented assignments: F1 and F2 select queue 0; F3, F4 and F5 select queue 1; F6 selects queue 3. In flow order, the queue assignments are [0, 0, 1, 1, 1, 3]. In queue order, the assigned flow counts are [2, 3, 0, 1]. There are six flows and four receive queues, with queue 2 receiving none of these flows. Six distinct flow identities did not force six different destinations or even use all four available queues. These counts supply no byte rates. Queue 1 has three assigned flows, but it could receive less traffic than queue 3's one flow. Nor do byte rates alone establish equal CPU work: the example specifies neither packet mix nor processing cost. The assignment therefore predicts no throughput, latency, fairness or CPU utilization, and prescribes no queue-to-CPU binding. Now examine the external-capacity claim. All six flows arrive through the one stipulated 100 Gb/s link. Four host receive queues do not turn it into four external links or raise its nominal rate to 400 Gb/s. They can provide separate destinations for work arriving through the same attachment. Dividing 100 Gb/s by four to promise each queue 25 Gb/s would be another unsupported interpretation. The example specifies no bandwidth reservation or per-queue entitlement. An unused queue is an unused destination for these flows; it is not a reserved quarter of the external link. The example is an assignment exercise, with no real NIC specification or test result. ## Ask what changes for one heavy flow Suppose F6 carries most of the fictional workload. Under the fixed mapping, adding more available queues does not make its unchanged flow identity select every queue in turn. Its receive work still enters through queue 3. The existence of other queues consequently cannot establish that this flow's processing bottleneck has been removed. That conclusion concerns the stated RSS selection step. It does not claim that every later operation for the application must execute on one CPU, or that a different architecture could never process the workload differently. It means that the supplier needs evidence for its actual per-flow performance claim beyond the advertised queue count. Ask the application owner whether the requirement concerns one flow, multiple concurrent flows or completion of a larger application task. One application may generate several flows; several application workers do not automatically establish how the selected RSS inputs distinguish their traffic. The traffic description must connect the application's requirement to the classification used by the offered receive path. Multi-queue support can still be useful when separate flows would otherwise concentrate receive work. An offer may improve processing parallelism while retaining exactly the same external port and nominal link rate. Whether it helps the intended workload remains an evaluation question. References: [M1](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling) ## Distinguish hardware RSS from later software steering Linux 6.18 places Receive Packet Steering, or RPS, later in the receive path. RPS chooses a CPU for protocol processing above the interrupt handler using software backlog queues. Hardware RSS and this later software step describe different selections. If a supplier shows receive processing on several CPUs, ask which mechanism accounts for the distribution. That observation alone cannot establish the number of hardware receive queues. Equally, identifying the hardware queue does not describe every subsequent CPU that might process the packet or application work. Keep that distinction in the offer description and evaluation record. It prevents crediting a NIC feature for processing distribution actually supplied elsewhere in the host stack. References: [K1](https://docs.kernel.org/6.18/networking/scaling.html) ## Compare the processing promise with the required result Start with the requirement the supplier is meant to satisfy. More independent external connections need a port and connection inventory. VM device assignments need the function-allocation description covered by the SR-IOV article. The linked breakout and aggregation article addresses external interface distribution. A need to distribute host receive processing calls for evidence about queues, traffic classification and CPU processing. For that last requirement, request the exact adapter, offered interface, firmware, driver and operating-system versions. Have the supplier identify the supported receive-queue resources actually available in that arrangement and the traffic types covered by its RSS claim. If VFs are involved, ask which queue resources belong to the particular allocation rather than substituting the adapter's total capability. A generic device-family maximum does not answer those questions. Then ask what supports the claimed application result. The evidence should identify the flow mix, packet sizes, concurrent load and receive direction represented, along with the meaning and units of the reported result. Application payload rate, packets processed per second and nominal port rate answer different questions. CPU processing observations can help explain a result; the advertised number of queues cannot replace it. Read the fictional six-flow assignment accordingly. It establishes that collisions in queue selection and an unused queue are possible. It cannot rank two adapters or determine the correct queue count. A many-flow demonstration also leaves a one-heavy-flow requirement unresolved unless that requirement is represented. The useful buying conclusion is whether the offered mechanism and evidence address the stated receive workload, not whether the largest queue number wins. ## Use the physical port plan when cabling work is required After the network and platform owners select the supported equipment arrangement, count its actual physical connections for the installation package. Receive queues introduce no additional cable endpoints in the example. Leviathan's Structured Cabling & Fiber Installation service can discuss installation of customer-supplied compatible assemblies, routing, dressing, labeling and agreed connection records. Use the service and project-inquiry links below to share the approved endpoints, routes, patching, material responsibilities, access window and required records. Queue configuration, CPU steering, network software and workload evaluation remain with the appointed platform and network owners. This article supports an offer comparison; it supplies no field procedure or approval to change a system. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [K1 — Linux 6.18: Scaling in the Linux Networking Stack](https://docs.kernel.org/6.18/networking/scaling.html). Checked 2026-10-20. Conventional RSS hash, indirection and interrupt relationships, plus the distinction between hardware queue selection and later software RPS. - [M1 — Microsoft Learn: Introduction to receive side scaling](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling). Checked 2026-10-20. Updated November 5, 2025. Windows RSS architecture and hardware-support levels; these do not specify a Linux driver's implementation or workload performance. - [M2 — Microsoft Learn: RSS with Hardware Queuing](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-with-hardware-queuing). Checked 2026-10-20. Updated December 15, 2021. Received buffers, hardware queues and CPU processing in the described Windows driver architecture; no measured gain is adopted. - [K2 — Linux 6.18: PCI Express I/O Virtualization Howto](https://docs.kernel.org/6.18/PCI/pci-iov-howto.html). Checked 2026-10-20. Overview of VF PCI configuration identity and register space. Function identity does not specify the offered NIC's queue or physical-port mapping. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Customer-supplied materials, approved pathways, physical installation and connection records. Network configuration is outside the published service scope. ## Related Leviathan resources - [Distinguish SR-IOV functions from physical network ports](/articles/nic-sriov-virtual-functions-versus-physical-ports) - [Compare Ethernet breakout with link aggregation](/articles/ethernet-breakout-versus-link-aggregation) - [Separate CPU memory locality from total host RAM](/articles/gpu-server-numa-local-memory-versus-total-ram) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Discuss the approved physical connection package](/contact?service=structured-cabling&from=%2Farticles%2Fnic-rss-receive-queues-versus-port-capacity) ## Scope cabling around the selected physical ports If physical cabling is required, share the approved endpoint schedule, customer-supplied assembly list, routes and handoff needs to discuss scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/nic-rss-receive-queues-versus-port-capacity)