On Fri, Mar 15, 2024 at 8:15 AM Sahil <icegambi...@gmail.com> wrote:
>
> Hi,
>
> Thank you for your email.
>
> On Thursday, March 14, 2024 8:39:45 PM IST Eugenio Perez Martin wrote:
> > Hi Sahil,
> >
> > It's being hard to find a good self-contained small task related to
> > the project to be honest. As it would be out of SVQ, would it be ok
> > for you if we start straight to the task of adding the packed vq
> > format to SVQ?
> >
> > Thanks!
>
> Sure, this works too! I would love to get started with the project.
>
> I have a small update as well. I have read through a few docs and
> articles to familiarize myself with the relevant terminology and
> technicalities.
>
> 1. "About", "system emulation" and "user mode emulation" sections of
>     the user documentation [1]
> 2. The migration subsystem [2]
>
> Some sections in the above docs were difficult to grasp. For the time
> being, I have focused on those parts that I thought were relevant
> to the project.
>

Please feel free to ask any questions, maybe we can improve the doc :).

> I have also read through the following articles:
>
> 1. Introduction to virtio-networking and vhost-net [3]
> 2. Deep dive into Virtio-networking and vhost-net [4]
> 3. Virtualized Hardware Devices [5]
> 4. VFIO - "Virtual Function I/O" (Just the introduction) [6]
> 5. Virtio-net failover: An introduction [7]
>
> I hope I haven't gone off on a tangent. I was planning to finish reading
> up on the following articles as well:
>

There is a post before the first in the series:
https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone

> 1. Virtqueues and virtio ring: How the data travels [8]
> 2. Packed virtqueue: How to reduce overhead with virtio [9]
> 3. Virtio live migration technical deep dive [10]
> 4. Hands on vDPA: what do you do when you ain't got the hardware v2 (Part 1) 
> [11]
>

I think it's a good plan!

If you feel like you're reading a lot of theory and want to get your
hands dirty already, you can also start messing with the code with the
blogs you already read. Or, maybe, after reading the Packed virtqueue
one, your call.

In a very brute-forced description, you can start trying to copy all
the *packed* stuff of kernel's drivers/virtio/virtio_ring.c into
vhost_shadow_virtqueue.c. There is a lot more in the task, and I can
get into more detail if you want either here or in a meeting.

If you prefer to continue with the theory it is ok too.

> I believe the hands-on vPDA article will have me set up a development
> environment for the project as well.
>

Yes, that's right.

> Please let me know if I should amend my roadmap. I am
> excited to get started :)
>

I think it is a great plan!

Thanks!

> Thanks,
> Sahil
>
> [1] https://www.qemu.org/docs/master/index.html
> [2] https://www.qemu.org/docs/master/devel/migration/index.html
> [3] 
> https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net
> [4] https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net
> [5] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_getting_started_guide/sec-virtualization_getting_started-products-virtualized-hardware-devices
> [6] https://www.kernel.org/doc/html/latest/driver-api/vfio.html
> [7] https://www.redhat.com/en/blog/virtio-net-failover-introduction
> [8] https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
> [9] 
> https://developers.redhat.com/articles/2024/02/21/virtio-live-migration-technical-deep-dive
> [10] 
> https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio
> [11] 
> https://www.redhat.com/en/blog/hands-vdpa-what-do-you-do-when-you-aint-got-hardware-part-1
>
>


Reply via email to