On 8/8/07, Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > That really doesn't seem right, I looked more at the block and the > console code, but it seems like there should be code which "claims" > posted DMA buffers and then the guest should have to re-post them.
That's how I would have designed it, and how I expected it to work, but it doesn't work that way. Once you do a bind for a dma descriptor, that's it -- and the enet code will happily overwrite that buffer. You have to move fast and have a few of them. See the handle_tun_input in lguest.c > a) follow the console driver style and just shuffle to named/pipe > socket to 9p server > b) follow the libos style and just use a shared memory buffer > posted in dev->mem that is mmaped from shared memory with the server > c) use dev->mem to store fcall slots and use the dma buffers to > shuffle payload -- this should be the optimal zero-copy case > > (a) can theoretically target any 9p server, (b) will work against > inferno-tx and (c) will work against a modified spfs and will take > some pretty heavy modifications to v9fs (don't need to marshall the > fcall, just stick it in a struct in shared memory). The idea is to > compare the performance of the three approaches and see just how much > cost (performance and complexity) is involved in each. Should have > (a) done in a matter of hours. When (a) is done let me know :-) ron
