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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Feb 22, 2017 at 09:19:41AM +0000, Gray, Mark D wrote:
> > 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?

DPDK is good.

You would then
- code up current proposal
- code up an alternative you are suggesting
- compare

tools/virtio/ringtest/ is only there to make prototyping
easier. I like keeping it alive for this purpose but it
is not a must.



> > 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.

Right. Obviously the system has to work well as a whole though, e.g. if
you save express bandwidth speeding up hardware but pay cache misses
slowing down software it's not clear you have won anything at all.


> > 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