On Tue, 2007-08-21 at 17:58 +1000, Rusty Russell wrote: > 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). >
I have certainly been known to take a similar stance when looking at Xen code ;) (recall the lapic work I did). However, that said I am not yet convinced that an out-of-order ring (at least as a fundamental primitive) buys us much. I think the use of rings for the tx-path in of itself is questionable unless you can implement something like the bidir NAPI that I demonstrated in ioqnet. Otherwise, you end up having to hypercall on each update to the ring anyway and you might as well hypercall directly w/o using a ring. At a fundamental level, I think we simply need an efficient and in-order (read: simple) ring to move data in, and a context associated hypercall to get out. We can also use that simple ring to move data out if its advantageous to do so (read: tx NAPI can be used). From there, we can build more complex constructs from these primitives, like out-of-order sg block-io. OTOH, its possible that its redundant to have a simple low-level infrastructure and then build a more complex ring for out-of-order processing on top of it. I'm not sure. My gut feeling is that it will probably result in a cleaner implementation: The higher-layered ring can stop worrying about the interrupt/hypercall details (it would use the simple ring as its transport)....and implementations that don't need out-of-order (e.g. networks) don't have to deal with the associated complexity. What are your thoughts to this layering approach? Regards, -Greg ------------------------------------------------------------------------- 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
