# PCI/PCIe(5): Latency Tolerance Reporting(LTR)

## Overview

為了優化系統的電源管理，在 PCIe 規格中定義了可選的 **Latency Tolerance Reporting(LTR)** 機制，目的是使 PCIe Endpoint(EP) 能夠回報其對記憶體讀寫到 Root Complex 延遲的要求。

這資訊能有助於平台考慮 EP 對服務的需求，以制定最佳的電源管理策略。例如，當平台進入低電源狀態時，如果裝置容忍較高的延遲，則可以晚點再從低電源狀態恢復過來，避免頻繁的在不同狀態來回切換。

EP 回報的 LTR 意義對於每個裝置不一定相同，可能攸關功能性或只對效能影響。對於 EP 回報的容忍延遲時間，Root complex 並不被要求需要嚴格滿足。但 PCIe 規範中強烈建議最差的服務延遲不超過 LTR 機制所提示的延遲。

如果不支援或未啟用 LTR 的 downstream port 接收到 LTR message，則該訊息會被視為 Unsupported Request 處理。

留意到 LTR 機制並不涉及本身的電源狀態，因此不會直接影響 Link power management 或 switch 內部的電源管理。儘管可能會產生間接影響。

## Configuration

LTR 的啟用是透過 "Device Control 2 Register (28h)" Bit 10 的 "LTR Mechanism Enable"。當設定為 1 時，表示允許 upstream port 發送 LTR message，並允許 downstream port 處理 LTR message。對於 downstream port，如果 port 進入 `DL_Down` 狀態，則必須將此 bit 重設為預設值。


除非 Root complext 和所有路徑上的 Switch 都表示支援 LTR，否則軟體不得在 EP 中啟用 LTR。但允許在同一個 bus 上有支援 LTR 的 EP 和不支援 LTR 的 EP 同時存在。此外，在啟用 LTR 機制的順序上，必須先啟用最靠近 Root complex 的裝置。

## LTR Messages


LTR Message 透過 Msg LTP (無 data payload 類型) 的訊息格式發送，如圖所示。


針對 no-snoop 和 snoop 兩種相異類型的請求，在 LTR Message 中存在各自的 field，裝置允許僅針對 No-Snoop/Snoop 或兩種類型的請求回報延遲提示。

Latency 欄位中包含一個 `Requiremenmt` 欄位，指示裝置是否對給定類型的 request 有延遲要求。如果 `Requirement` 值被設為 1，則 `LatencyValue` 和 `LatencyScale` 欄位可以結合起來描述對延遲時間的要求。
* 如果 `Requirement` 設為 0，則表示裝置或沒有該種類型的請求，或者沒有對延遲的要求
* 如果 `Requirement` 設為 1 且 `LatencyValue` 和 `LatencyScale` 皆為 0，表示任何延遲都會對裝置帶來影響

## 小結

考慮到 PCIe 裝置的電源狀態轉換，以及結構中不同的部件，例如 Multi-Function Devices(MFD), Switch 等，在 PCIe 標準中制訂了 LTR 設定須遵守的規則細節。詳情請參考 PCIe 規範的 6.18 Latency Tolerance Reporting (LTR) Mechanism。