On Fri, Feb 7, 2025 at 8:48 AM Hanna Czenczek <hreitz@xxxxxxxxxx> wrote: > > On 07.02.25 14:41, Stefan Hajnoczi wrote: > > On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@xxxxxxxxxx> wrote: > >> On 28.01.25 17:16, Stefan Hajnoczi wrote: > >>> Dear QEMU and KVM communities, > >>> QEMU will apply for the Google Summer of Code internship > >>> program again this year. Regular contributors can submit project > >>> ideas that they'd like to mentor by replying to this email by > >>> February 7th. > >>> > >>> About Google Summer of Code > >>> ----------------------------------------- > >>> GSoC (https://summerofcode.withgoogle.com/) offers paid open > >>> source remote work internships to eligible people wishing to participate > >>> in open source development. QEMU has been doing internship for > >>> many years. Our mentors have enjoyed helping talented interns make > >>> their first open source contributions and some former interns continue > >>> to participate today. > >>> > >>> Who can mentor > >>> ---------------------- > >>> Regular contributors to QEMU and KVM can participate as mentors. > >>> Mentorship involves about 5 hours of time commitment per week to > >>> communicate with the intern, review their patches, etc. Time is also > >>> required during the intern selection phase to communicate with > >>> applicants. Being a mentor is an opportunity to help someone get > >>> started in open source development, will give you experience with > >>> managing a project in a low-stakes environment, and a chance to > >>> explore interesting technical ideas that you may not have time to > >>> develop yourself. > >>> > >>> How to propose your idea > >>> ------------------------------ > >>> Reply to this email with the following project idea template filled in: > >>> > >>> === TITLE === > >>> > >>> '''Summary:''' Short description of the project > >>> > >>> Detailed description of the project that explains the general idea, > >>> including a list of high-level tasks that will be completed by the > >>> project, and provides enough background for someone unfamiliar with > >>> the code base to research the idea. Typically 2 or 3 paragraphs. > >>> > >>> '''Links:''' > >>> * Links to mailing lists threads, git repos, or web sites > >>> > >>> '''Details:''' > >>> * Skill level: beginner or intermediate or advanced > >>> * Language: C/Python/Rust/etc > >> === Asynchronous request handling for virtiofsd === > >> > >> '''Summary:''' Make virtiofsd’s request handling asynchronous, allowing > >> single-threaded parallel request processing. > >> > >> virtiofsd is a virtio-fs device implementation, i.e. grants VM guests > >> access to host directories. In its current state, it processes guest > >> requests one by one, which means operations of long duration will block > >> processing of others that could be processed more quickly. > >> > >> With asynchronous request processing, longer-lasting operations could > >> continue in the background while other requests with lower latency are > >> fetched and processed in parallel. This should improve performance > >> especially for mixed workloads, i.e. one guest process executing > >> longer-lasting filesystem operations, while another runs random small > >> read requests on a single file. > >> > >> Your task is to: > >> * Get familiar with a Linux AIO interface, preferably io_uring > >> * Have virtiofsd make use of that interface for its operations > >> * Make the virtiofsd request loop process requests asynchronously, so > >> requests can be fetched and processed while others are continuing in the > >> background > >> * Evaluate the resulting performance with different workloads > >> > >> '''Links:''' > >> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd > >> * virtiofsd’s filesystem operations: > >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490 > >> * virtiofsd’s request processing loop: > >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244 > >> > >> '''Details:''' > >> * Skill level: intermediate > >> * Language: Rust > >> * Mentors: Hanna Czenczek (hreitz@xxxxxxxxxx), German Maglione > >> (gmaglione@xxxxxxxxxx) > > Thanks, I have added your project idea to the list: > > https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd > > Thanks! > > > Do you want to give any guidance on which crate to use for > > asynchronous I/O? Do you want async Rust (e.g. tokio) or not? > > That would depend entirely on the student. I’m open for async Rust > (tokio or even homegrown), but they could also decide they’d rather do > it in some different manner (e.g. with callbacks that would return > descriptors to the guest). I’ll add that info, if that’s OK. Sounds good. Stefan
