On Mon, Apr 03, 2023 at 02:57:26PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <m...@redhat.com> > > Sent: Monday, April 3, 2023 10:53 AM > > > > On Fri, Mar 31, 2023 at 05:43:11PM -0400, Parav Pandit wrote: > > > > I can not say I thought about this > > > > deeply so maybe there's some problem, or maybe it's a worse approach > > > > - could you comment on this? It looks like this could be a smaller > > > > change, but maybe it isn't? Did you consider this option? > > > > > > We can possibly let both the options open for device vendors to implement. > > > > > > Change wise transport VQ is fairly big addition for both hypervisor > > > driver and also for the device. > > > > 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. > > 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? > 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? > 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. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
