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. > 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
