RDMA zero page compression sends an RDMA_CONTROL_COMPRESS message instead of an RDMA Write, but the transfer accounting (mig_stats.rdma_bytes and ram_transferred_add) was not updated. This caused migration progress and bandwidth to be undercounted.
Account the wire cost (RDMAControlHeader + RDMACompress payload), matching how the non-RDMA path accounts for zero page markers. Reviewed-by: Li Zhijian <[email protected]> Signed-off-by: Bin Guo <[email protected]> --- migration/rdma.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/migration/rdma.c b/migration/rdma.c index 201cb9eb12..f08468881f 100644 --- a/migration/rdma.c +++ b/migration/rdma.c @@ -1930,15 +1930,15 @@ retry: } /* - * TODO: Here we are sending something, but we are not - * accounting for anything transferred. The following is wrong: - * - * stat64_add(&mig_stats.rdma_bytes, sge.length); - * - * because we are using some kind of compression. I - * would think that head.len would be the more similar - * thing to a correct value. + * Account for the control message we just sent. + * The actual bytes on the wire are the control header + * plus the RDMACompress payload, not the original page + * size (which was never transferred). */ + qatomic_add(&mig_stats.rdma_bytes, + sizeof(RDMAControlHeader) + sizeof(RDMACompress)); + ram_transferred_add(sizeof(RDMAControlHeader) + + sizeof(RDMACompress)); qatomic_add(&mig_stats.zero_pages, sge.length / qemu_target_page_size()); return 1; -- 2.50.1 (Apple Git-155)
