RE: [virtio-dev] packed ring layout proposal - todo list

["Gray, Mark D" <mark.d.gray@intel.com>]

> From: virtio-dev@lists.oasis-open.org [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@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org