 |
|
Mapping Packets to Processors
To generate a 32-bit signature, Receive-Side Scaling (RSS) requires the hash function to be calculated over a specific set of fields in the packet header. The set of fields over which the hash is computed is set by the configuration OID. If the hash type flags enable only one type of hash, then any packet that is received that does not match that hash type is not hashed. (For definitions of hash type flags, see “RSS Initialization” earlier in this paper.) For example, if the TCP/IPv4 4-tuple hash type is set and a packet that is not a TCP packet arrives (for example, an IP fragment, or a User Datagram Protocol (UDP) packet, or an IPsec-encrypted packet), a hash is not performed on the packet. If multiple flags are set—for example, if the TCP/IPv4 and IPv4 hash types are enabled—then if the packet is not a TCP/IPv4 packet but is an IPv4 packet (for example, an IPsec-encrypted packet), the hash is performed on just the IPv4 2-tuple. Further, for this setting of the hash type flags, if the incoming packet is not an IPv4 packet, then no hash is performed. Because a variety of hash types can be applied on a per-packet basis (including no hash), the hash type is indicated to the host protocol stack on a per‑packet basis. If no hash was performed, then none of the hash type flags are set.
As mentioned previously, the hash signature for each packet is masked and then used to index into the indirection table, and then added to BaseCPUNumber to determine the processor that the packet should be processed on (that is, the processor that runs the DPC). Figure 2 shows a specific example of the contents of the indirection table and how it can be changed, assuming that a four processor configuration is used and that the configuration OID set the number of least significant bits for the hash result mask to be 6 bits and the BaseCPUNumber to zero. This configuration implies that the indirection table contains 64 entries.
In Figure 2, Table A shows the values immediately after initialization. After some time has elapsed and as normal traffic load varies, the processor load will grow unbalanced. The host protocol stack will then detect the unbalanced condition and attempt to rebalance the load by calculating a new indirection table and passing it to the miniport driver using the configuration OID. Table B in Figure 2 shows the new indirection table, which moved some of the load off of CPU 2 and onto CPUs 1 and 3.
When the indirection table is changed, it is possible for a short period of time (while the current receive descriptor queues are being processed) for packets to be processed on the wrong CPU. This is a normal transient condition.
Figure 2 Example: RSS indirection table
Because the host protocol stack needs to change the processing load on each of the processors by varying the contents of the table, the size of the table in Figure 2 will typically reach two to eight times the number of processors in the system.
RSS Data Reception
NDIS data reception is usually completed first by the interrupt service routine that is located in the MiniportInterrupt function handler, which queues a DPC and eventually calls the MiniportInterruptDPC function handler. When the DPC is ready to indicate the packet to the host protocol stack, it initializes the following fields in the NetBufferList data structure:
· RSS hash function
· RSS hash type (if no hash was calculated, then none of the hash type flags are set)
· RSS hash value (including all 32 bits)
The data reception enables protocol layers above the miniport adapter to leverage the work that was done by the RSS-enabled network adapter. It also enables the host protocol stack to detect if the packet in question was hashed with a prior hash function or hash type.
When specific RSS algorithm processing is completed depends on the implementation. For more information about RSS algorithm processing, see "RSS Implementation" later in this paper.
RSS Implementation
This section defines three Receive-Side Scaling (RSS) implementation options. Options defined here are for illustration purposes and are not meant to define the only methods to implement support for RSS. This section examines the abstract data structures and sequence of operations, explains how interrupts and DPCs are scheduled, and contrasts the advantages and disadvantages of each approach.