接收端調整第 2 版 （RSSv2）
接收端調整可改善在多處理器系統上處理網路數據的相關系統效能。 NDIS 6.80 和更新版本支援 RSS 第 2 版 （RSSv2），其可藉由提供佇列的動態、每個 VPort 散佈來擴充 RSS。
概觀
相較於 RSSv1，RSSv2 會縮短 CPU 負載測量和更新間接數據表之間的時間。 這可避免在高流量情況下變慢。 為了達成此目的，RSSv2 會在處理要求的處理器內容中，於 IRQL = DISPATCH_LEVEL 執行其動作，而且只會在指向目前處理器的間接數據表專案子集上運作。 這表示 RSSv2 可以動態分散接收佇列到多個處理器，比 RSSv1 更有回應。
RSSv2 中引進了兩個 OID，OID_GEN_RECEIVE_SCALE_PARAMETERS_V2和OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES，分別為迷你埠驅動程式設定適當的 RSS 功能並控制間接取值數據表。 OID_GEN_RECEIVE_SCALE_PARAMETERS_V2是一般 OID，而 OID_GEN_RSS_SET_INDIRECTION_ENTRIES 是無法傳回NDIS_STATUS_PENDING的同步 OID。 如需這些 OID 的詳細資訊，請參閱其個別參考頁面。 如需同步 OID 的詳細資訊，請參閱 NDIS 6.80 中的同步 OID 要求介面。
RSSv2 術語
本主題使用下列詞彙：
| 詞彙 | 定義 |
|---|---|
| RSSv1 | 第一代接收端調整機制。 使用 OID_GEN_RECEIVE_SCALE_PARAMETERS。 |
| RSSv2 | 本主題所述，Windows 10 版本 1803 和更新版本中支援的第二代接收端調整機制。 |
| 調整實體 | 原生 RSS 模式中的迷你埠配接器本身，或 RSSv2 模式中的 VPort。 |
| 這兒 | 指定縮放實體的間接數據表專案 （ITE）。 每個 VPort 的 ITE 總數不能超過 NumberOfIndirectionTableEntriesPerNonDefaultPFVPort 或 VmQ 模式中的 NumberOfIndirectionTableEntriesForDefaultVPort ，或原生 RSS 案例中的 128。 NumberOfIndirectionTableEntriesPerNonDefaultPFVPort 和 NumberOfIndirectionTableEntriesForDefaultVPort 是NDIS_NIC_SWITCH_CAPABILITIES結構的成員。 |
| 調整模式 | 控制 ITE 在運行時間處理方式的個別 VPort vmswitch 原則。 這可能是靜態的（由於負載變更而沒有ITE移動）或動態（根據目前的流量負載而展開和聯合）。 |
| 佇列 | 基礎硬體物件（佇列）可備份 ITE。 視硬體和間接數據表而定，組態佇列可能會支援多個 ITE。 佇列總數，包括預設佇列所使用的佇列總數，不能超過系統管理員通常設定的預先設定限制。 |
| 默認處理器 | 接收無法計算哈希之封包的處理器。 每個 VPort 都有預設處理器。 |
| 主要處理器 | 在 VPort 建立期間，指定為 NDIS_NIC_SWITCH_VPORT_PARAMETERS 結構的 ProcessorAffinity 成員的處理器。 此處理器可以在運行時間更新，並指定 VMQ 流量的導向位置。 |
| 來源 CPU | ITE 目前對應的處理器。 |
| 目標 CPU | ITE 要重新對應的處理器（使用 RSSv2）。 |
| 動作專案 CPU | 正在提出 RSSv2 要求的處理器。 |
在迷你埠驅動程式中公告 RSSv2 功能
迷你埠驅動程式會使用 NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE 旗標設定 NDIS_RECEIVE_SCALE_CAPABILITIES 結構的 CapabilitiesFlags 成員，以公告 RSSv2 支援。 若要啟用 RSSv2 的 CPU 負載平衡功能，以及 啟用非預設 VPorts （VMQs） 的 RSSv1 動態平衡NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED 旗標，則需要具備這項功能。
注意
上層通訊協定假設預設 VPort 的主要處理器可以移動 RSSv2 迷你埠驅動程式。
如果迷你埠適配卡未公告 RSSv2 功能，則即使要求這些 VPort 執行動態分散，所有已啟用 VMQ 的 VPorts 仍會維持在靜態傳播模式中。 RSSv1 OID 用於設定 RSS 參數， OID_GEN_RECEIVE_SCALE_PARAMETERS，用於仍在靜態傳播模式的這些 VPort。
迷你埠驅動程式只需要實作一個 RSS 控制機制 - RSSv1 或 RSSv2。 如果驅動程式公告 RSSv2 支援，NDIS 會視需要將 RSSv1 OID 轉換為 RSSv2 OID，以設定每個 VPort 散佈。 迷你埠驅動程序必須支援兩個新的 OID，並修改 RSSv1 OID_GEN_RECEIVE_SCALE_PARAMETERS OID 的行為，如下所示：
- OID_GEN_RECEIVE_SCALE_PARAMETERS僅用於 RSSv2 中的查詢要求，而不是用於設定 RSS 參數。
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2是一個查詢和設定 OID，用來設定調整實體的參數，例如佇列數目、ITE 數目、RSS 啟用/停用和哈希密鑰更新。
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES是方法 OID，用來執行間接取值數據表專案的修改。
處理 RSSv2 OID
OID_GEN_RECEIVE_SCALE_PARAMETERS僅用於查詢指定縮放實體目前的 RSS 參數。 在 RSSv1 中，此 OID 是用來設定參數。 針對支援 RSSv2 的迷你埠驅動程式，NDIS 會自動為驅動程式執行此角色轉換，併發出下列兩個 OID 來改為設定參數。
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2是一般 OID，處理方式與 RSSv1 中處理OID_GEN_RECEIVE_SCALE_PARAMETERS OID 相同。 在 NDIS 6.80 之前，NDIS 輕量篩選驅動程式 （LFS） 看不到此 OID。
不過，OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES是無法傳回NDIS_STATUS_PENDING的同步 OID。 此 OID 必須在源自 OID 的處理器內容中執行並完成。 如同OID_GEN_RECEIVE_SCALE_PARAMETERS_V2，NDIS LDF 在 NDIS 6.80 之前也看不到它。 NDIS 6.80 和更新版本中的LDF不允許延遲此OID或移至另一個處理器。 其承載包含簡單的「移動 ITE」動作陣列，每個動作都包含一個命令，以將調整實體的單一 ITE 移至不同的目標 CPU。 陣列的元素可以參考不同的縮放實體 （VPorts）。
每種類型的 NDIS 驅動程式、迷你連接埠、篩選和通訊協定都有支援同步 OID 要求介面的進入點：
| NDIS 驅動程序類型 | 同步 OID 處理程式（秒） | 產生同步 OID 的函式 |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/A |
| 篩選器 | NdisFSynchronousOidRequest | |
| 通訊協定 | N/A | NdisSynchronousOidRequest |
RSS 狀態轉換、ITE 更新和主要/預設處理器
轉向參數
在RSSv2中，不同的參數可用來根據 RSS 狀態（已啟用或停用）將流量導向正確的 CPU。 停用 RSS 時，只會使用主要處理器來引導流量。 啟用 RSS 時，預設處理器和所有 ITE 都會用於引導流量。 下表摘要說明這些 轉向參數 標示為「使用中」或「非使用中」：
| 轉向參數 | RSS 已停用 | 已啟用 RSS |
|---|---|---|
| 主要處理器 | 使用中 | 非使用中 |
| 默認處理器 | 非作用中 | 使用中 |
| ITE[0..N] | 非作用中 | 使用中 |
當轉向參數處於作用中狀態時，它會導向流量。 從 RSS 狀態轉換讓參數 變成非使用中的那一刻起，迷你埠驅動程式必須追蹤參數的變更，直到反向轉換再次啟動它為止。 這表示迷你埠驅動程序必須追蹤默認處理器和間接數據表專案的所有更新，同時停用該縮放實體的 RSS。 啟用 RSS 時，預設處理器和間接存取數據表的目前追蹤狀態應該生效。
例如，請考慮軟體 vRSS 已啟用時的案例。 在此情況下，間接數據表已存在於上層通訊協定中，而且會由上層的軟體散佈程式代碼主動使用。 如果在硬體 RSS 啟用期間，在更新 行動 間接數據表專案之前，指向主要處理器的所有專案都會發出並由硬體執行，則主要處理器可能會遇到短暫的干擾。 如果迷你埠驅動程式已追蹤默認處理器和 ITE 資訊，它可以將流量導向到上層已預期的位置。
請注意，雖然迷你埠驅動程序必須追蹤非使用中轉向參數的所有更新，但它們應該延遲這些參數的驗證，直到 RSS 狀態變更嘗試讓這些參數 變成作用中為止。 例如，在硬體 RSS 停用時軟體散佈的情況下，上層通訊協定可以使用任何處理器進行散佈（包括適配卡的 RSS 集合外部）。 上層可確保在 RSS 狀態轉換時，所有 非 使用中的參數都適用於新的 RSS 狀態。 不過，如果迷你埠驅動程序發現任何追蹤 的非使用 中轉向參數無效，仍應驗證參數，並讓 RSS 狀態轉換失敗。
導向參數的初始狀態和更新
下表描述建立后調整實體的初始狀態（例如 VPort 建立之後），以及如何更新參數：
| 參數 | 描述 |
|---|---|
| 主要處理器 |
|
| 默認處理器 |
|
| 間接取值數據表 |
|
更新 ITE 和主要/預設處理器（使用 OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES）從對應進入目前指向的處理器叫用。 對於指定的 VPort，上層可確保不會有OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID 移動 ITE 或設定主要/預設處理器，在這些情況下：
- 當OID_GEN_RECEIVE_SCALE_PARAMETERS_V2進行時。
- 起始 VPort 刪除順序之後。 例如，上層只會在最後一個 OID 完成移動 ITE 之後，才會發出設定篩選 OID。
RSS 停用
在 RSS 停用期間，上層通訊協定可能會選擇將所有 ITE 指向主要處理器，然後發出 OID 以停用 RSS，或者可能會選擇依原狀保留間接數據表並停用 RSS。 不論是哪一種情況，接收流量都應該以主要處理器為目標。
RSSv2 會維護 RSSv1 的需求，允許上層通訊協定刪除 VPort，而不需要先停用 RSS。 上層可以將 VPort 上的接收篩選器設定為零，因此確保不會接收流量流經 VPort，然後繼續進行 VPort 刪除，而不停用 RSS。 上層保證 VPort 刪除期間或之後不會發出任何OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID。
在 RSS 停用和 VPort 刪除期間，迷你埠驅動程式應該負責任何可能因為先前佇列移動而存在的擱置內部作業。
RSSv2 不變量
上層通訊協定可確保在執行管理功能或 ITE 移動之前，不會違反重要的不因數。 例如：
- 在減少佇列數目之前，上層可確保間接數據表不會參考比 VPort 的新佇列數目更多的處理器。
- 上層不應要求間接數據表更新，該更新違反 VPort 目前設定的佇列數目。 迷你埠驅動程式應該強制執行此動作，並傳回失敗。
- 在變更 VMMQ-RESTRICTED 適配卡的間接數據表項目數目之前，上層可確保間接轉換數據表的內容會正規化為 2 的電源。
相關連結
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2