| RFC-0114：內嵌 FIDL 信封中的小值 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 此 RFC 提議變更 FIDL 線的格式，將值 <= 4 位元組的大小套用至郵件內文。 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-24 |
| 審查日期 (年-月-日) | 2021-07-21 |
摘要
此 RFC 提議變更 FIDL 線段的格式，變更內嵌值 <= 4 個位元組的 尺寸導入信封。
提振精神
這項異動的動機是提高 FIDL 資料表的效能 聯集 (例如目前使用信封的版面配置)。
FIDL 聯集和資料表針對非線物件使用共用表示法 稱為信封離站指標是已知的負擔來源 編碼器-解碼器架構小型物件可以內嵌在信封中 因此也不必投入資源結構耗用資源。
此外，在某些情況下，您也可以減少分配金額。改為 物件是系統分配物件的外線位置，並從 信封，物件可以直接儲存在信封中。
設計
本 RFC 設計假設 RFC-0113，介紹有效率的信封。
下列類型會使用新的內嵌值格式：
- 布林值
- float32
- uint8、uint16、uint32
- int8、int16、int32
- 含有版面配置 uint8、uint16、uint32、int8、int16、int32 的列舉
- 含有版面配置 uint8、uint16、uint32、int8、int16、int32 的位元
- handle、client_end、server_end
- 結構體 <= 4 個位元組
- 陣列大小 <= 4 個位元組
如果日後新增了類型值，大小小於 4 位元組， 除非另有說明，否則也會使用內嵌值格式。
新格式可以透過 C-struct 表示法描述：
// An envelope corresponds to a union value or an entry in a table.
struct Envelope {
union {
// Inlined values have the same envelope structure for both wire and
// decoded formats.
InlinedValueEnvelope inlined_value_envelope;
// Out-of-line values have a different structure on the wire and in
// decoded format.
union OutOfLineEnvelope {
// Wire representation.
OutOfLineWireEnvelope out_of_line_wire_envelope;
// Decoded representation.
void* decoded_data;
};
};
};
struct InlinedValueEnvelope {
// A <= 4-byte value stored little-endian and 0-padded up to 4-bytes.
uint8_t value[4];
// Number of handles within the envelope.
uint16_t num_handles;
// Bit 0 of flags is 1 to indicate the inline representation is used and
// the envelope is present.
uint16_t flags;
};
struct OutOfLineWireEnvelope {
// Number of bytes recursively within the envelope.
uint32_t num_bytes;
// Number of handles recursively within the envelope.
uint16_t num_handles;
// Bit 0 of flags is 0 to indicate the out-of-line representation is used.
uint16_t flags;
}
InlinedValueEnvelope 和 OutOfLineWireEnvelope 兩種線路表示法
有 flags 個欄位重疊。flags 中的 LSB 會指出
使用或不內嵌表單：1 代表內嵌表單，0 代表不行。所有語言
未使用的標記位元必須為 0。
FIDL 中只有一個標準的資料表示法。 呈現大小不超過 4 個位元組的值。這個值必須內嵌，且值超過 4 個位元組「必須」使用外線表示法。收到值不正確的收據 表示法「必須」觸發解碼錯誤 缺少的信封會繼續採用零信封表示法， 一律會以離線方式表示。
實作
這項變更需要複雜的遷移作業。不過，這項遷移作業 而且搭配其他傳輸格式遷移，因此 練習。
成效
欄位內嵌時，LLPP 中的編碼時間大幅縮短 (CL)：
對已設定所有欄位的時間進行編碼時間 (以奈秒為單位)：
| # 欄位 | 使用前 | 使用後 |
|---|---|---|
| 1 | 178 奈秒 | 147 奈秒 |
| 16 | 720 奈秒 | 325 奈秒 |
| 256 | 9396 奈秒 | 2909 奈秒 |
這張圖表顯示編碼時間，是資料表內含欄位數量的函式。 已設定表格中的所有欄位。
解碼時間沒有測量，但預期會有很大的幫助 會遵循一系列類似的步驟 編碼器-解碼器架構
此外，在某些情況下，繫結或許能避免進行配置 這樣也能進一步提升成效
人體工學
這個 RFC 允許繫結避免配置較小的值，但不允許 就是指揮等等如果繫結確實有所變更，API 就能正常運作 這很可能與適合用來處理資料的 API 不同 其他需要分配的類型這種不一致可能會導致效能低落 必須從事人體工學和照護才能避免這種情況
回溯相容性
這項變更所需的遷移作業會破壞 ABI 相容性。
不過，一旦變更生效，ABI 的相容性就不會受到影響 瞭解類型變更所有小於 4 位元組的型別都不保證 ABI 保證 在此變更前後，類型相容性都會變更。
這項變更「可能會破壞來源相容性」。沒有來源相容性中斷問題 執行變更，但繫結 可能選擇做為來源 相容性破壞性變更 (如果能改善繫結效能) 或其他原因
安全性考量
這不會對安全性造成影響。
隱私權注意事項
這不會對隱私權造成任何影響。
測試
有幾種策略來測試變更：
- 在每個繫結中自訂單元測試。
- GIDL 合規套件。
- FIDL 相容性測試。
說明文件
電線格式說明文件必須更新。
效能的取捨必須記錄在 API 評分量表中 欄位大小決策
缺點、替代方案和未知
缺點
這個提案的主要缺點是複雜度提高。現在 有兩種值表示：內嵌和非行，具體取決於類型 而您可能出乎意料的是 行為
替代方法：8 位元組內嵌值
此 RFC 建議內嵌 4 個位元組以下的值。 原因是似乎無法內嵌到 8 位元組的值 - 至少搭配有效率而導入時至少 信封。
原因是繫結必須支援未知的信封。時間 收到不明信封，無法取得類型資訊。因此 不知道它是否指向外部物件 變更解碼器的行為因此 值本身，並指出該值是否以 內嵌或離線格式。
若信封大小為 8 個位元組，且內嵌值是 8 個位元組， 如果是內嵌或非行式格式，您就不需要儲存任何位元。
因此，8 位元組內嵌值不符合效率 信封。必須做一個選擇，不要使用有效率的信封 或縮減可內嵌的值大小。這個 RFC 使 因為這個方向 改善成效
既有藝術品和參考資料
RFC-0113 導入有效率的信封，構成信封結構的基礎 用於此 RFC 路徑的