Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07)

["ron minnich" <rminnich@gmail.com>]

On 8/8/07, Eric Van Hensbergen <ericvh@gmail.com> 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