On Tue, 2007-08-21 at 00:33 -0700, Dor Laor wrote: > >> > 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. Partly the horror of the code, but mainly because it is an in-order ring. You'll note that we use a reply ring, so we don't need to know how much the other side has consumed (and it needn't do so in order). Cheers, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
