On Mon, Mar 25, 2024 at 3:18 PM Heng Qi <hengqi@xxxxxxxxxxxxxxxxx> wrote: > > > > 在 2024/3/25 下午1:57, Jason Wang 写道: > > On Mon, Mar 25, 2024 at 10:21 AM Heng Qi <hengqi@xxxxxxxxxxxxxxxxx> wrote: > >> > >> > >> 在 2024/3/22 下午1:19, Jason Wang 写道: > >>> On Thu, Mar 21, 2024 at 7:46 PM Heng Qi <hengqi@xxxxxxxxxxxxxxxxx> wrote: > >>>> Currently, ctrlq processes commands in a synchronous manner, > >>>> which increases the delay of dim commands when configuring > >>>> multi-queue VMs, which in turn causes the CPU utilization to > >>>> increase and interferes with the performance of dim. > >>>> > >>>> Therefore we asynchronously process ctlq's dim commands. > >>>> > >>>> Signed-off-by: Heng Qi <hengqi@xxxxxxxxxxxxxxxxx> > >>> I may miss some previous discussions. > >>> > >>> But at least the changelog needs to explain why you don't use interrupt. > >> Will add, but reply here first. > >> > >> When upgrading the driver's ctrlq to use interrupt, problems may occur > >> with some existing devices. > >> For example, when existing devices are replaced with new drivers, they > >> may not work. > >> Or, if the guest OS supported by the new device is replaced by an old > >> downstream OS product, it will not be usable. > >> > >> Although, ctrlq has the same capabilities as IOq in the virtio spec, > >> this does have historical baggage. > > I don't think the upstream Linux drivers need to workaround buggy > > devices. Or it is a good excuse to block configure interrupts. > > Of course I agree. Our DPU devices support ctrlq irq natively, as long > as the guest os opens irq to ctrlq. > > If other products have no problem with this, I would prefer to use irq > to solve this problem, which is the most essential solution. Let's do that. Thanks > > > > > And I remember you told us your device doesn't have such an issue. > > YES. > > Thanks, > Heng > > > > > Thanks > > > >> Thanks, > >> Heng > >> > >>> Thanks >
