mirror of
https://github.com/qemu/qemu.git
synced 2026-07-08 17:46:10 +00:00
84005f4a2b
The kernel allocates extra metadata SKBs in case of a zerocopy send, eventually used for zerocopy's notification mechanism. This metadata memory is accounted for in the OPTMEM limit. The kernel queues completion notifications on the socket error queue and this error queue is freed when userspace reads it. Usually, in the case of in-order processing, the kernel will batch the notifications and merge the metadata into a single SKB and free the rest. As a result, it never exceeds the OPTMEM limit. However, if there is any out-of-order processing or intermittent zerocopy failures, this error chain can grow significantly, exhausting the OPTMEM limit. As a result, all new sendmsg requests fail to allocate any new SKB, leading to an ENOBUF error. Depending on the amount of data queued before the flush (i.e., large live migration iterations), even large OPTMEM limits are prone to failure. To work around this, if we encounter an ENOBUF error with a zerocopy sendmsg, flush the error queue and retry once more. Co-authored-by: Manish Mishra <manish.mishra@nutanix.com> Signed-off-by: Tejus GK <tejus.gk@nutanix.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [DB: change TRUE/FALSE to true/false for 'bool' type; add more #ifdef QEMU_MSG_ZEROCOPY blocks] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>