RE: [PATCH 00/11] Introduce transitional mmr pci device

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, April 3, 2023 11:07 AM

> > > OTOH it is presumably required for scalability anyway, no?
> > No.
> > Most new generation SIOV and SR-IOV devices operate without any para-
> virtualization.
> 
> Don't see the connection to PV. You need an emulation layer in the host if you
> want to run legacy guests. Looks like it could do transport vq just as well.
>
Transport vq for legacy MMR purpose seems fine with its latency and DMA overheads.
Your question was about "scalability".
After your latest response, I am unclear what "scalability" means.
Do you mean saving the register space in the PCI device?
If yes, than, no for legacy guests for scalability it is not required, because the legacy register is subset of 1.x.

 
> > > And presumably it can all be done in firmware ...
> > > Is there actual hardware that can't implement transport vq but is
> > > going to implement the mmr spec?
> > >
> > Nvidia and Marvell DPUs implement MMR spec.
> 
> Hmm implement it in what sense exactly?
>
Do not follow the question.
The proposed series will be implemented as PCI SR-IOV devices using MMR spec.
 
> > Transport VQ has very high latency and DMA overheads for 2 to 4 bytes
> read/write.
> 
> How many of these 2 byte accesses trigger from a typical guest?
> 
Mostly during the VM boot time. 20 to 40 registers read write access.

> > And before discussing "why not that approach", lets finish reviewing "this
> approach" first.
> 
> That's a weird way to put it. We don't want so many ways to do legacy if we can
> help it.
Sure, so lets finish the review of current proposal details.
At the moment 
a. I don't see any visible gain of transport VQ other than device reset part I explained.
b. it can be a way with high latency, DMA overheads on the virtqueue for read/writes for small access.