[Rust-VMM] Call for GSoC and Outreachy project ideas for summer 2022

[Stefano Garzarella]

On Mon, Feb 14, 2022 at 02:01:52PM +0000, Stefan Hajnoczi wrote:
>On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang at redhat.com> wrote:
>>
>> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>> >
>> > Dear QEMU, KVM, and rust-vmm communities,
>> > QEMU will apply for Google Summer of Code 2022
>> > (https://summerofcode.withgoogle.com/) and has been accepted into
>> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
>> > submit internship project ideas for QEMU, KVM, and rust-vmm!
>> >
>> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
>> > be a mentor. It's a great way to give back and you get to work with
>> > people who are just starting out in open source.
>> >
>> > Please reply to this email by February 21st with your project ideas.
>> >
>> > Good project ideas are suitable for remote work by a competent
>> > programmer who is not yet familiar with the codebase. In
>> > addition, they are:
>> > - Well-defined - the scope is clear
>> > - Self-contained - there are few dependencies
>> > - Uncontroversial - they are acceptable to the community
>> > - Incremental - they produce deliverables along the way
>> >
>> > Feel free to post ideas even if you are unable to mentor the project.
>> > It doesn't hurt to share the idea!
>>
>> Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
>> (vhost/virtio drivers) would be an interesting idea.
>>
>> It satisfies all the points above since it's supported by virtio spec.
>>
>> (Unfortunately, I won't have time in the mentoring)
>
>Thanks for this idea. As a stretch goal we could add implementing the
>packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
>QEMU's virtio qtest code.
>
>Stefano: Thank you for volunteering to mentor the project. Please
>write a project description (see template below) and I will add this
>idea:
>

I wrote a description of the project below. Let me know if there is 
anything to change.

Thanks,
Stefano



=== VIRTIO_F_IN_ORDER support for virtio devices ===

'''Summary:''' Implement VIRTIO_F_IN_ORDER feature for QEMU and Linux
(vhost/virtio drivers)

The VIRTIO spec defines a feature bit (VIRTIO_F_IN_ORDER) that devices
and drivers can negotiate when they are able to use descriptors in the
same order in which they have been made available.

This feature could allow to simplify the implementation and develop
optimizations to increase performance. For example, when
VIRTIO_F_IN_ORDER is negotiated, it may be easier to create batch of
buffers and reduce the amount of notification needed between devices
and drivers.

Currently the devices and drivers available on Linux and QEMU do not
support this feature. An implementation is available in DPDK for the
virtio-net driver.

The project could start with implementation for a single device/driver
in QEMU and Linux, then generalize it into the virtio core for split
and packed virtqueue layouts.

If time allows we could develop the support for packed virtqueue layout
in Linux vhost, QEMU's libvhost-user, and/or QEMU's virtio qtest code.

'''Links:'''
* [https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html VIRTIO spec 1.1]
** [https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-470009 "In-order use of descriptors" section for split virtqueues]
* [https://github.com/oasis-tcs/virtio-spec Source code for the VIRTIO spec]
* [https://mails.dpdk.org/archives/dev/2018-July/106069.html Patches that introduced VIRTIO_F_IN_ORDER in DPDK]
* [https://lists.oasis-open.org/archives/virtio/201803/msg00048.html Patch that introduced VIRTIO_F_IN_ORDER in VIRTIO spec]
* [https://patchew.org/QEMU/1533833677-27512-1-git-send-email-i.maximets@samsung.com/ Incomplete implementation proposed for QEMU]

'''Details:'''
* Skill level: intermediate
* Language: C
* Mentor: Stefano Garzarella <sgarzare at redhat.com>
** IRC/Matrix nick: sgarzare (OFTC/matrix.org)
* Suggested by: Jason Wang <jasowang at redhat.com>