On Thu, 3 Apr 2025 10:35:33 -0400 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Thu, Apr 03, 2025 at 04:18:36PM +0200, Halil Pasic wrote: > > On Wed, 2 Apr 2025 22:36:21 +0200 [..] > > > > 5.5.2 Virtqueues > > > > 0 > > inflateq > > 1 > > deflateq > > 2 > > statsq > > 3 > > free_page_vq > > 4 > > reporting_vq > > Indeed. Unfortunately, no one at all implemented this properly as > per spec :(. > > Balloon is the worst offender here but other devices are broken > too in some configurations. > > > Given it has been like this for many years I'm inclined in this > instance to fix the spec not the implementations. > I understand! For me at least knowing if we are going to change the spec or the implementations is pretty important. It would probably make sense to spin a patch for the spec, just for the unlikely case that somebody did end up implementing this by the spec and wants to protest. I think, a consequence of this design is that all queues need to be created and allocated at initialization time. I mean in the spec we have something like """ 5.1.6.5.6.1 Driver Requirements: Automatic receive steering in multiqueue mode The driver MUST configure the virtqueues before enabling them with the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command. """ For example one could want to hotplug 2 more vCPUs and still have a queue-pair per cpu (and a controlq). Those 2 extra queue-pairs could in theory be allocated on-demand instead of having to allocate memory for the rings for all the queues corresponding to the maxed out setup. I've had a look at the Linux virtio-net and it does allocate all the queues up front. Also with this design, I believe we would effectively prohibit "holes". Now if holes are prohibited, IMHO it does not make a whole lot of sense for the virtio_find_vqs() to support holes. Because the holes and a fair amount of complexity. Of course that would make sense as a cleanup on top. Regards, Halil
