On Wed, Feb 22, 2017 at 09:19:41AM +0000, Gray, Mark D wrote: > > 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? 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@xxxxxxxxxxxxxxxxxxxx > > For additional commands, e-mail: virtio-dev-help@xxxxxxxxxxxxxxxxxxxx _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
