Re: [Qemu-devel] [RFC PATCH V3 3/4] colo-compare: introduce packet comparison thread

[Dr. David Alan Gilbert]

* Zhang Chen (address@hidden) wrote:
> 
> 
> 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
> >>zhangchen
> >I 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.

Of course always check what I've written; some of that branch
was quite hacky itself so don't just assume it's good!

Dave

> 
> Thanks
> Zhang Chen
> 
> >.
> >
> 
> -- 
> Thanks
> zhangchen
> 
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK