On Thu, Sep 21, 2023 at 02:44:50PM -0300, Jason Gunthorpe wrote: > On Thu, Sep 21, 2023 at 01:21:26PM -0400, Michael S. Tsirkin wrote: > > Yea it's very useful - it's also useful for vdpa whether this patchset > > goes in or not. At some level, if vdpa can't keep up then maybe going > > the vfio route is justified. I'm not sure why didn't anyone fix iommufd > > yet - looks like a small amount of work. I'll see if I can address it > > quickly because we already have virtio accelerators under vdpa and it > > seems confusing to people to use vdpa for some and vfio for others, with > > overlapping but slightly incompatible functionality. I'll get back next > > week, in either case. I am however genuinely curious whether all the new > > functionality is actually useful for these legacy guests. > > It doesn't have much to do with the guests - this is new hypervisor > functionality to make the hypervisor do more things. This stuff can > still work with old VMs. > > > > > Another question I'm interested in is whether there's actually a > > > > performance benefit to using this as compared to just software > > > > vhost. I note there's a VM exit on each IO access, so ... perhaps? > > > > Would be nice to see some numbers. > > > > > > At least a single trap compared with an entire per-packet SW flow > > > undoubtably uses alot less CPU power in the hypervisor. > > > > Something like the shadow vq thing will be more or less equivalent > > then? > > Huh? It still has the entire netdev stack to go through on every > packet before it reaches the real virtio device. No - shadow vq just tweaks the descriptor and forwards it to the modern vdpa hardware. No net stack involved. > > That's upstream in qemu and needs no hardware support. Worth comparing > > against. Anyway, there's presumably actual hardware this was tested > > with, so why guess? Just test and post numbers. > > Our prior benchmarking put our VPDA/VFIO solutions at something like > 2x-3x improvement over the qemu SW path it replaces. > Parav said 10% is lost, so 10% of 3x is still 3x better :) > > I thought we all agreed on this when vdpa was created in the first > place, the all SW path was hopeless to get high performance out of? > > Jason That's not what I'm asking about though - not what shadow vq does, shadow vq is a vdpa feature. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization