Re: [PATCH 00/10] PV-IO v3

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>]

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.



-------------------------------------------------------------------------
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/