[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Can we remove the logic of preventing MSI irq storms


  • To: Haitao Shan <maillists.shan@xxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Thu, 14 Jul 2011 08:06:59 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 14 Jul 2011 00:08:06 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcxB9J91hbUF9kZBIE2LISXY/MVsaw==
  • Thread-topic: Can we remove the logic of preventing MSI irq storms

On 14/07/2011 07:43, "Haitao Shan" <maillists.shan@xxxxxxxxx> wrote:

> Hi, Keir,
> 
> As you may remember (see c/s 17960), Xen implemented the logic of
> preventing MSI irq storms. The reason of the IRQ storm at that time is
> still unknown. But the logic is definitely needed at that time since
> that NIC is the only device at my hand to test MSI.
> The idea is simple: mask the second MSI interrupt when the first one
> is still in processing. For HVM guests, we hooked at guest EOI write
> to determime whether the first MSI is serviced already.
> 
> However, recently we find the logic has negative impact on 10G NIC
> performance (assigned to guest). The logic lowers the interrupt
> frequency that Xen can handle. It is a problem when the device is
> generating too many interrupts as seen in this 10G NIC.
> 
> And now there is IRQ rate limit logic in Xenm which can also help to
> prevent IRQ storms.
> 
> Given all the above, do you think it is time to remove the logic of
> preventing MSI IRQ storm?

I'd be happy to see it go.

 -- Keir

> Shan Haitao



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.