Problem
Three findings from the adversarial review of #172, each real but low impact, decided against rather than fixed so the PR stayed focused on the hang.
The break warnings are not throttled. #172 batches the malformed-chain count into one warn! per kick, because a guest can post a malformed chain for every buffer in its ring. The batch-bound, ring-validation, and writability warnings still emit one line each per kick, on the vCPU thread, and a guest kicks at will. The multiplier is far smaller — at most one line per kick per site — but it is the same shape.
rx_buffer uses Vec with remove(0). Shedding the oldest frame at the 1024-frame ceiling memmoves ~1023 Vec headers, not payloads, and only when the guest is consuming no RX at all. VecDeque with pop_front removes the question and reads better. This is a clarity change, not a performance one — the measurement says the current code is fine.
MAX_TX_FRAME_BYTES is a ceiling the driver is never told about. The device does not offer VIRTIO_NET_F_MTU, so a driver has no way to learn the largest frame this device will accept. The value covers a frame at Linux's max_mtu of 65535 carrying two 802.1Q tags, so nothing a Linux driver can hand over lands above it — but a private limit on a wire path is worth either advertising or documenting as deliberately unadvertised.
Proposed change
Take them together or separately; none blocks anything. The MTU one needs a decision before code: advertising VIRTIO_NET_F_MTU changes what the device negotiates, which is a wire-visible change and wants its own justification.
Problem
Three findings from the adversarial review of #172, each real but low impact, decided against rather than fixed so the PR stayed focused on the hang.
The
breakwarnings are not throttled. #172 batches the malformed-chain count into onewarn!per kick, because a guest can post a malformed chain for every buffer in its ring. The batch-bound, ring-validation, and writability warnings still emit one line each per kick, on the vCPU thread, and a guest kicks at will. The multiplier is far smaller — at most one line per kick per site — but it is the same shape.rx_bufferusesVecwithremove(0). Shedding the oldest frame at the 1024-frame ceiling memmoves ~1023Vecheaders, not payloads, and only when the guest is consuming no RX at all.VecDequewithpop_frontremoves the question and reads better. This is a clarity change, not a performance one — the measurement says the current code is fine.MAX_TX_FRAME_BYTESis a ceiling the driver is never told about. The device does not offerVIRTIO_NET_F_MTU, so a driver has no way to learn the largest frame this device will accept. The value covers a frame at Linux'smax_mtuof 65535 carrying two 802.1Q tags, so nothing a Linux driver can hand over lands above it — but a private limit on a wire path is worth either advertising or documenting as deliberately unadvertised.Proposed change
Take them together or separately; none blocks anything. The MTU one needs a decision before code: advertising
VIRTIO_NET_F_MTUchanges what the device negotiates, which is a wire-visible change and wants its own justification.