[randomizedcoder]

• virtio_net (and other drivers without a known speed) reports SPEED_UNKNOWN (-1) from get_link_ksettings; homa_qdev_update_sysctl used it, giving link_mbps -1 and a negative max_nic_queue_bytes.
• Result: every deferrable packet is deferred and never sent. With the homa qdisc on a virtio NIC, echo, cp_node Homa and TCP all stall (0 Kops, ~1170 RESENDs, pacer_homa_packets 0).
• A speed of 0 would divide by zero in the cycles_per_mibyte calculation.
• Fix: fall back to homa->link_mbps for 0 and SPEED_UNKNOWN.
• Test: homa_qdev_update_sysctl__link_speed_unknown (red: link_mbps -1, cycles_per_mibyte 1953; green: 885/885).
• Found by: two-VM pair lifecycle with the homa qdisc on eth1 (round-4 candidate 5).

🤖 Generated with Claude Code

[breakertt]

Hi Dave,

I am also using virtio, thank for your this great work.

May I ask are you using gso_force_software or set maximal gso size to MTU. virtio by default doesn’t sent chunk the skb on the “wire”, so receiver will just receive a big skb - which Homa AFAIK unable to process. Maybe I am wrong as I am always using gso_force_software.

Problem is gso_force_software will perform GSO on the skb, the segment function is not optimized for Homa. We can either fix it properly let Homa able to handle a raw skb before actual GSO, or improve the performance of the segment.

Cheers,
Tianyi

[randomizedcoder]

Hi Tianyi,

Thanks! Neither: we run Homa's defaults, so gso_force_software is 0 and max_gso_size stays at 1000. With that, homa_message_out_init computes max_gso_segs = 1, so Homa never builds a GSO skb and every packet goes out at MTU size.

Our two VMs are also linked by a QEMU dgram (UDP) netdev, not a tap. That backend has no vnet header, so QEMU doesn't offer TSO or guest offloads on the virtio-net device, and a large skb couldn't reach the receiver whole anyway.

So we haven't tested the case you describe (tap/vhost with host TSO, where the receiver gets one big skb). That seems separate from this PR, which only stops the qdisc from using SPEED_UNKNOWN as a link speed. If it would help, I can add a variant of our VM pair test that uses a tap backend with max_gso_size=100000 and no gso_force_software, to see whether the receiver copes.

Some background on where these PRs come from: we've built a testing harness in Nix that builds Homa against a range of kernels and boots it in QEMU microVMs, including a two-VM pair test (traffic, netem loss and delay, Homa's qdisc and pacer, rmmod) on regular, KASAN/lockdep/UBSAN and KCSAN kernels. It also runs the unit tests with coverage, static analysis, netdev's checks on the make net-next files, and fuzzing. All five PRs I just opened were found by it:

• Wait for route RCU callbacks in homa_peer_free_net #144: KASAN use-after-free in homa_route_free (VM smoke test)
• Ignore unknown link speed in homa_qdev_update_sysctl #145: SPEED_UNKNOWN on virtio-net (pair test with Homa's qdisc)
• Use mem_cgroup_from_sk in homa_rpc_alloc_server #146: build failure without CONFIG_MEMCG (netdev's in-tree builds)
• Don't walk route_ht while holding peertab->lock #147: lockdep lock-order inversion (KASAN/lockdep VM)
• Annotate lockless reads in homa_qdisc_deferred_offset #148: KCSAN data race (KCSAN pair test)

We're hoping to submit the Nix harness as its own PR soon, for discussion and review.

Cheers,
Dave

[breakertt]

Hi Dave,

Thank you, I see your use case. but overall I think we should leverage TSO and also the feature that virtio doesn’t chunk gso skb, for better performance.

Nix harnesses
Sounds exciting, looking forward to!

Cheers,
Tianyi