perf(orchestrator): increase NBD dispatch buffer by 28 bytes to coalesce header + max payload in one read

packages/orchestrator/pkg/sandbox/nbd/dispatch.go の dispatchBufferSize から始め、周辺の NBD dispatch ロジックを読みます。raw buffer を 28 バイトのヘッダーサイズ分増やし、その後、既存の NBD パッケージチェックを確認します。完了条件は、他の動作を変更せずに、バッファがヘッダー付きの 4 MB ペイロードを格納できることです。

Summary

The NBD dispatch read buffer (dispatchBufferSize) is set to exactly 4 MB, which is the maximum data payload size. However, every NBD request also carries a 28-byte header. This means a maximum-size read (4 MB data + 28-byte header) requires two kernel reads instead of one — the header and data cannot be received in a single recv() call.

Location: packages/orchestrator/pkg/sandbox/nbd/dispatch.go:54

// TODO: Look into optimizing the buffer reads by increasing the buffer size by 28 bytes,
// to account for a request that is 28 bytes of header + 4MB of data (this seems to be preferred kernel buffer size).
dispatchBufferSize = 4 * 1024 * 1024

Root cause

The NBD protocol frames each request as [28-byte header][N bytes payload]. When the kernel sends a 4 MB write, the dispatch loop reads the 28-byte header, then refills the buffer with up to dispatchBufferSize bytes of payload. If dispatchBufferSize == 4 MB, a 4 MB write payload fills the entire buffer, leaving no room to pre-read the next request's header in the same syscall.

Increasing the buffer by exactly 28 bytes allows the tail of one response and the header of the next to be coalesced into a single read.

Proposed fix

// dispatchBufferSize is the raw read buffer for the NBD socket.
// 4MB covers the largest possible data payload; the extra 28 bytes
// let the next request's header arrive in the same read as the
// last byte of the previous payload, saving one syscall per request.
dispatchBufferSize = 4*1024*1024 + 28

This is a single-constant change with no behavioral risk — the buffer is used only for reading from the NBD socket.

Impact

Every NBD read or write request currently requires at least two recv() calls for max-size payloads. Reducing to one call per request lowers syscall overhead for I/O-intensive sandboxes (particularly those doing large sequential reads/writes to the virtual block device).