On Mon, Oct 16, 2023 at 11:00:36AM -0600, Jeffrey Hugo wrote: > From: Carl Vanderlip <quic_carlv@xxxxxxxxxxx> > > Several virtualization use-cases either don't support 32 MultiMSIs > (Xen/VMware) or have significant drawbacks to their use (KVM's vIOMMU, > which is required to support 32 MSI, needs to allocate an alternate > system memory space for each device using vIOMMU (e.g. 8GB VM mem and > 2 cards => 8 + 2 * 8 = 24GB host memory required)). Support these > cases by enabling a 1 MSI fallback mode. > > Whenever all 32 MSIs requested are not available, a second request for > a single MSI is made. Its success is the initiator of single MSI mode. > This mode causes all interrupts generated by the device to be directed > to the 0th MSI (firmware >=v1.10 will do this as a response to the PCIe > MSI capability configuration). Likewise, all interrupt handlers for the > device are registered to the 0th MSI. > > Since the DBC interrupt handler checks if the DBC is in use or if > there is any pending changes, the 'spurious' interrupts are > disregarded. If there is work to be done, the standard threaded IRQ > handler is dispatched. > > On every interrupt, the MHI handler wakes up its threaded interrupt > handler, and attempts to wake any waiters for MHI state events. > > Performance is within +-0.6% for test cases that typify real world > use. Larger differences ([-4,+132]%, avg +47%) exist for very simple > tasks (e.g. addition) compiled for single NSPs. It is assumed that the > small work and many interrupts typically cause contention (e.g. 16 NSPs > vs 4 CPUs), as evidenced by the standard deviation between runs also > decreasing (r=-0.48 between delta(Performace_test) and > delta(StdDev_test/Avg_test)) > > Signed-off-by: Carl Vanderlip <quic_carlv@xxxxxxxxxxx> > Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@xxxxxxxxxxx> > Reviewed-by: Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> > Signed-off-by: Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@xxxxxxxxxxxxxxx>
