On Mon, Mar 25, 2024 at 4:22 PM Heng Qi <hengqi@xxxxxxxxxxxxxxxxx> wrote: > > > > 在 2024/3/25 下午3:56, Jason Wang 写道: > > 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. > > Ok, will do. > > Do you have the link to the patch where you previously modified the > control queue for interrupt notifications. > I think a new patch could be made on top of it, but I can't seem to find it. Something like this? https://lore.kernel.org/lkml/6026e801-6fda-fee9-a69b-d06a80368621@xxxxxxxxxx/t/ Note that 1) some patch has been merged 2) we probably need to drop the timeout logic as it's another topic 3) need to address other comments THanks > > Thanks, > Heng > > > > > Thanks > > > >>> And I remember you told us your device doesn't have such an issue. > >> YES. > >> > >> Thanks, > >> Heng > >> > >>> Thanks > >>> > >>>> Thanks, > >>>> Heng > >>>> > >>>>> Thanks >
