|
From: | Zhang Chen |
Subject: | Re: [Qemu-devel] [RFC PATCH V3 3/4] colo-compare: introduce packet comparison thread |
Date: | Fri, 29 Apr 2016 16:28:48 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
On 04/29/2016 10:07 AM, Jason Wang wrote:
On 04/28/2016 06:31 PM, Zhang Chen wrote:+/* + * called from the compare thread on the primary + * for compare connection + */ +static void colo_compare_connection(void *opaque, void *user_data) +{ + Connection *conn = opaque; + Packet *pkt = NULL; + GList *result = NULL; + int ret; + + qemu_mutex_lock(&conn->list_lock); + while (!g_queue_is_empty(&conn->primary_list) && + !g_queue_is_empty(&conn->secondary_list)) { + pkt = g_queue_pop_head(&conn->primary_list); + result = g_queue_find_custom(&conn->secondary_list, + pkt, (GCompareFunc)colo_packet_compare_all); + + if (result) { + ret = compare_chr_send(pkt->s->chr_out, pkt->data, pkt->size); + if (ret < 0) { + error_report("colo_send_primary_packet failed"); + } + trace_colo_compare_main("packet same and release packet"); + g_queue_remove(&conn->secondary_list, result->data); + } else { + trace_colo_compare_main("packet different"); + g_queue_push_head(&conn->primary_list, pkt);Is this possible that the packet from secondary has not been arrived on time? If yes, do we still need to notify the checkpoint here?Yes,the packet of secondary may not arrived. we will hold primary packet to next periodic checkpoint to flush it. and more, I consider to set a timer to flush timeout(200ms???) packet like Dave's branch. Thanks zhangchenI was wondering maybe you can merge or unify all other changes from Dave's branch?
Yes, I will unify some codes from Dave's colo-proxy branch. Thanks Zhang Chen
.
-- Thanks zhangchen
[Prev in Thread] | Current Thread | [Next in Thread] |