From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Fri, 25 May 2007 18:11:35 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] XML In-Reply-To: <13426df10705251115g494cb819k881854e8a7952fe8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 72fa6bb0-ead2-11e9-9d60-3106f5b1d025 On Fri May 25 14:15:01 EDT 2007, rminnich@gmail.com wrote: > It hit me that the dom0 could export its tcp stack to dom1 as a > paravirtual device. you could bypass the silly virtual enet emulation > that way. Your /net would go right to the tcp, not via some odd > pseudo-device. That would save some delay and overhead, and, not > incidentally, would make my mp3 player smoother in dom1 ... muxing a /net heirarchy from plan9 via 9p is certainly the most flexable way to go. this is a very good idea. (i assume that you really didn't mean importing tcp only from dom0.) however, there are some hardware models that could be very efficient to emulate in /a/ hypervisor. the myricom 10gbe moves all data by dma. the only mmio is for commands, send descriptors (16 bytes) and receive descriptors (8 bytes). assuming the guest doesn't have real pci window addresses, dom0 would only need to rewrite the descriptors and the card could still dma directly from the guest. it's significantly less general than the 9p way of doing things, but it could make zero-copy sends (and zero-copy tco, if you care about such things) doable. i don't know enough about xen's inner workings to know if this would work. - erik p.s. perhaps the way to put generality back in is to marshal 9p between dom0 and guests with the same trick. use an pseudo-mmio descriptor for the 9p "header" which points to the memory to be transfered.