在 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.
Thanks,
Heng
Thanks
And I remember you told us your device doesn't have such an issue.
YES.
Thanks,
Heng
Thanks
Thanks,
Heng
Thanks
