# 虛擬化 HW4

## lab3-1

## lab3-2

### 問題
1. 請簡要說明fentry跟tracepoint的差異在哪裡。 (20 points)
- fentry 會直接掛在某個 kernel 函式入口，例如 tcprtt 是掛在 TCP 相關函式（如 tcp_connect 或 TCP 狀態更新函式）上，透過 BTF 自動取得函式參數與結構體欄位，寫程式時可以像平常呼叫參數一樣存取 socket、srtt 等欄位
- tracepoint 則是核心開發者預先放好的事件點，例如 tcprtt_tp 掛在 sock/inet_sock_set_state，由核心填好 trace_event_raw_inet_sock_set_state 結構（包含 oldstate/newstate、ip、port、skaddr 等），eBPF 程式只能用這個結構中提供的欄位來做運算
3. fentry跟tracepoint的差異是否有帶來tcprtt程式表現上的差異? 為什麼? (20 points)
- tcprtt（fentry 版）在函式入口直接讀取 TCP 控制區塊中的 RTT 相關欄位（例如 srtt），再更新 map 或 histogram；tcprtt_tp（tracepoint 版）則是在每次 TCP 狀態改變的 tracepoint 被觸發時，從事件結構裡拿到 skaddr、ip、port，配合 map 中紀錄的時間戳計算 RTT，最後透過 ring buffer/perf event 回傳至 user space
- 兩者在本 lab 都只是做：查/寫一個 hash map、取目前時間或 RTT 欄位，再送一次事件，整體邏輯與計算量非常接近，因此在實際執行時，RTT 結果的準確度與程式執行時間不會出現明顯差別；fentry 雖然在理論上呼叫鏈較短、開銷略低，但對這種低頻、輕量追蹤來說差距通常小到難以量測
- 真正的差異比較像是「介面與適用情境」：fentry 必須有對應的 BTF 與內核函式符號，適合直接讀取函式參數或內部結構；tracepoint 則比較穩定、版本相容性好，而且像 inet_sock_set_state 這種事件一觸發就代表「狀態已改變」，自然非常方便用來做 TCP RTT 這類基於狀態轉換的量測，因此實作上選 tracepoint 比較直觀