On Wed, 20 May 2026 18:07:08 +0200 Stefano Brivio wrote: > On Wed, 20 May 2026 17:34:45 +0200 > Stefano Brivio wrote: > > > On Wed, 13 May 2026 13:52:08 +0200 > > Laurent Vivier wrote: > > > > > Currently, the vhost-user path assumes each virtqueue element contains > > > exactly one iovec entry covering the entire frame. This assumption > > > breaks as some virtio-net drivers (notably iPXE) provide descriptors where the > > > vnet header and the frame payload are in separate buffers, resulting in > > > two iovec entries per virtqueue element. > > > > > > This series refactors the vhost-user data path so that frame lengths, > > > header sizes, and padding are tracked and passed explicitly rather than > > > being derived from iovec sizes. This decoupling is a prerequisite for > > > correctly handling padding of multi-buffer frames. > > > > Sorry to bring (likely) bad news, but this series seems to introduce a > > regression: I got the migration/rampstream_in tests fail twice in a > > row, which I've never saw happening (I think I saw a single failure a > > long time ago when the machine had a high CPU load, but nothing else). > > > > I'm currently bisecting and the bisect seems to point towards the end > > of the series (probably 10/10), but I haven't finished yet. I'll keep > > you posted. I haven't spotted anything that might cause issues there. > > Yeah, that's the one :( > > $ git bisect bad > db798fc60f4c5869cb53168354e068fb4dabd91a is the first bad commit > commit db798fc60f4c5869cb53168354e068fb4dabd91a > Author: Laurent Vivier > Date: Wed May 13 13:52:18 2026 +0200 > > vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() > > The "TCP/IPv4: sequence check, ramps, inbound" test in rampstream_in > gets stuck, once the source is done with the migration, and passt on the > destination just printed: > > Accepted TCP_REPAIR helper, PID 13 > accepted connection from PID 16 > > I'll get captures and logs next. It seems to fail most of the times, > I had two failures in a row again. Log from passt --debug attached. Likely highlight: --- 13.2853: ================ Vhost user message ================ 13.2853: Request: VHOST_USER_SET_VRING_ADDR (9) 13.2853: Flags: 0x1 13.2853: Size: 40 13.2853: vhost_vring_addr: 13.2853: index: 0 13.2853: flags: 0 13.2853: desc_user_addr: 0x00007f0943f41000 13.2853: used_user_addr: 0x00007f0943f42240 13.2854: avail_user_addr: 0x00007f0943f42000 13.2854: log_guest_addr: 0x000000001ff43240 13.2854: Setting virtq addresses: 13.2854: vring_desc at 0x7f2e2e2ca000 13.2854: vring_used at 0x7f2e2e2cb240 13.2854: vring_avail at 0x7f2e2e2cb000 13.2854: Last avail index != used index: 2163 != 1936 13.2854: Got packet, but RX virtqueue not usable yet --- pcap file of that passt instance empty, it didn't have a chance to send/receive packets yet. -- Stefano