> From: virtio-dev@xxxxxxxxxxxxxxxxxxxx [mailto:virtio-dev@lists.oasis- > open.org] On Behalf Of Michael S. Tsirkin > > Here is an attempt to summarise the list of things we need to do with respect > to this proposal. Thanks for outlining this, it makes it a lot clearer. > > > Stage 1: update prototype and finalize proposal > > At this stage we need to update the prototype under > tools/virtio/ringtest/ring.c to make it match latest proposal, adding in verious Would a DPDK based prototype be good aswell or would you rather everything be prototyped here? > options under discussion. > Then we will measure performance. While more ideas are welcome there > won't be useful without ability to test! > > Tasks: > > - update tools/virtio/ringtest/ring.c to proposal, adding > options as listed below. > - compare performance with and without indirect buffers > issue: how to estimate cost of memory allocations? > - batching descriptors - is it worth it? > - three ways to suppress interrupts/exits > which works better? > issue: how to estimate cost of interrupts/exits? > > We need to ensure we have a proposal that is suitable for implementation in hardware. > More ideas: > > - current tests all indicate cache synchronizations due to r/w descriptors > cost as much as read-only/write-only descriptors, > and there are less of these synchronizations. > Disagree? Write a patch and benchmark. > - some devices could use smaller descriptors. For example, > if you don't need length, id (e.g. using in-order, fixed length) or flags, you > can > use a single 64 bit pointer as a descriptor. This can sometimes work > e.g. for networking rx rings. > Not clear whether this gains/costs us anything. Disagree? Write a patch and > benchmark. > > Stage 2: prototype guest/host drivers > > At this stage we need real guest and host drivers to be able to test real life > performance. > I suggest dpdk drivers + munimal hack in qemu to pass features around. > > Tasks: > > - implement vhost-user support in dpdk > - implement virtio support in dpdk > - implement minimal stub in qemu > - test performance. Possibly revisit questions from stage 2 > if any are left open > > > Stage 3: complete guest/host drivers > > At this stage we need to add linux support in virtio and vhost, and complete > qemu support. > > Tasks: > > - implement vhost support in kernel > - implement virtio support in kernel > - complete virtio support in qemu > - test performance. Possibly revisit questions from stage 2 > if any are left open > > > > Stage X: Finalizing the spec > > When are we ready to put out a spec draft? Surely not before Stage 1 is > done. Surely no later than stage 3. A driver could be wish for some party to > productize an implementation. > > Interested? Join TC and start discussion on timing and which features should > be included. > > > -- > MST > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx > For additional commands, e-mail: virtio-dev-help@xxxxxxxxxxxxxxxxxxxx _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
