> From: Eugenio Perez Martin <eperezma@xxxxxxxxxx> > Sent: Tuesday, May 17, 2022 4:12 AM > > 2. Each VQ enablement one at a time, requires constant steering update > > for the VQ While this information is something already known. Trying to > reuse brings a callback result in this in-efficiency. > > So better to start with more reusable APIs that fits the LM flow. > > We can change to that model later. Since the model proposed by us does not > add any burden, we can discard it down the road if something better arises. > The proposed behavior should already work for all > devices: It comes for free regarding kernel / vdpa code. It is not for free. It comes with higher LM downtime. And that makes it unusable as the queues scale. > > I think that doing at vhost/vDPA level is going to cause the same problem as > VRING_SET_BASE: We will need to maintain two ways of performing the > same, and the code will need to synchronize them. I'm not *against* adding > it by itself, I'm just considering it an optimization that needs to be balanced > against what already enables the device to perform state restoring. We only need to change the sequencing of how we restore and abstract it out how to restore in the vdpa layer. CVQ or something else it the choice internal inside the vpda vendor driver. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
