>> > Well, for cache reasons you should really try to avoid having both >sides >> > write to the same data. Hence two separate cache-aligned regions is >> > better than one region and a flip bit. >> >> While I certainly can see what you mean about the cache implications >for >> a bit-flip design, I don't see how you can get away with not having >both >> sides write to the same memory in other designs either. Wouldn't you >> still have to adjust descriptors from one ring to the other? E.g. >> wouldn't both sides be writing descriptor pointer data in this case, >or >> am I missing something? > >Hi Gregory, > > You can have separate produced and consumed counters: see for >example >Van Jacobson's Netchannels presentation >http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf page 23. > > This single consumed count isn't sufficient if you can consume >out-of-order: for that you really want a second "reply" ringbuffer >indicating what buffers are consumed. >
Rusty, although your code works pretty nice, (I'll send some raw patches later on today with kvm support for virtio). I was wandering why didn't you use Xen's ring implementation? They have separate counters and also union for the request/response structure in the same descriptor. Here is some of it + lxr link: http://81.161.245.2/lxr/http/source/xen/include/public/io/ring.h?v=xen-3 .1.0-src;a=m68k 80 #define DEFINE_RING_TYPES(__name, __req_t, __rsp_t) \ 81 \ 82 /* Shared ring entry */ \ 83 union __name##_sring_entry { \ 84 __req_t req; \ 85 __rsp_t rsp; \ 86 }; \ 87 \ 88 /* Shared ring page */ \ 89 struct __name##_sring { \ 90 RING_IDX req_prod, req_event; \ 91 RING_IDX rsp_prod, rsp_event; \ 92 uint8_t pad[48]; \ 93 union __name##_sring_entry ring[1]; /* variable-length */ \ 94 }; \ 95 \ 96 /* "Front" end's private variables */ \ 97 struct __name##_front_ring { \ 98 RING_IDX req_prod_pvt; \ 99 RING_IDX rsp_cons; \ 100 unsigned int nr_ents; \ 101 struct __name##_sring *sring; \ 102 }; \ 103 \ 104 /* "Back" end's private variables */ \ 105 struct __name##_back_ring { \ 106 RING_IDX rsp_prod_pvt; \ 107 RING_IDX req_cons; \ 108 unsigned int nr_ents; \ 109 struct __name##_sring *sring; \ 110 }; \ 111 \ 112 /* Syntactic sugar */ \ 113 typedef struct __name##_sring __name##_sring_t; \ 114 typedef struct __name##_front_ring __name##_front_ring_t; \ 115 typedef struct __name##_back_ring __name##_back_ring_t ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
