Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent > even queque overrun > > Michael S. Tsirkin wrote: > >> Sorry, i dont follow. If you arm the CQ when there is one WC in it and > >> then start polling, and during your polling a "second" WC is generated > >> by the HCA, wouldn't an interrupt related to the 2nd completion be > >> generated - why the case you are mentioning is the arming window? > > > I'm polling in the interrupt handler, so interrupts from the same IRQ are > > disabled. No? What am I missing? > > OK, i might be somehow newbee around this (working in hard irq context) > land. Does disabling the HCA IRQ means no interrupt would be generated > later when the handler is done? i was think it would be just deffered. AFAIK, you get another interrupt only if hardware continues asserting the interrupt. > iSER hard irq CQ handler just does a context jump to soft irq handler > (tasklet) so the rule you mention does not apply to it. > -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Michael S. Tsirkin wrote: Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a "second" WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? I'm polling in the interrupt handler, so interrupts from the same IRQ are disabled. No? What am I missing? OK, i might be somehow newbee around this (working in hard irq context) land. Does disabling the HCA IRQ means no interrupt would be generated later when the handler is done? i was think it would be just deffered. iSER hard irq CQ handler just does a context jump to soft irq handler (tasklet) so the rule you mention does not apply to it. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz <[EMAIL PROTECTED]>: > Sorry, i dont follow. If you arm the CQ when there is one WC in it and > then start polling, and during your polling a "second" WC is generated > by the HCA, wouldn't an interrupt related to the 2nd completion be > generated - why the case you are mentioning is the arming window? I'm polling in the interrupt handler, so interrupts from the same IRQ are disabled. No? What am I missing? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Michael >>> I am seeing EQ overruns in SDP stress tests: if CQ completion Michael >>> handler arms a CQ, this could generate more EQEs, Or >> I see that the mad, ipoib and srp CQ handlers work as follows: first - Or >> arm the CQ, second - poll the CQ in a loop till it is emtpy. Or >> does it means that completions occurring while the handler is running cause Or >> interrupts which could be saved? Michael > Handlers are running out of the interrupt context, so Michael > an interrupt would have to be generated in the window while Michael > CQ is being armed. Profiling I've done on ipoib shows that Michael > this is quite unlikely. Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a "second" WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz <[EMAIL PROTECTED]>: > > I am seeing EQ overruns in SDP stress tests: if CQ completion > > handler arms a CQ, this could generate more EQEs, so that > > EQ will never get empty and consumer index will never get updated. > > There's something re CQ arming which i'd like to bring up. > > I see that the mad, ipoib and srp CQ handlers work as follows: first - > arm the CQ, second - poll the CQ in a loop till it is emtpy. What is the > reasoning behind this approach? Thats what IB spec says. > does it means that completions occurring > while the handler is running cause interrupts which could be saved? Handlers are running out of the interrupt context, so an interrupt would have to be generated in the window while CQ is being armed. Profiling I've done on ipoib shows that this is quite unlikely. > is there any problem with first empty-ing the CQ and only then arming it? > > The latter approach is taken by iser code. As far as i understand it can > not cause the ib consumer to miss interrupts, am i wrong? On Mellanox hardware you wont miss interrupts in this case if you always poll CQ and then arm it as a result of an interrupt. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Michael, Roland Michael S. Tsirkin wrote: I am seeing EQ overruns in SDP stress tests: if CQ completion handler arms a CQ, this could generate more EQEs, so that EQ will never get empty and consumer index will never get updated. There's something re CQ arming which i'd like to bring up. I see that the mad, ipoib and srp CQ handlers work as follows: first - arm the CQ, second - poll the CQ in a loop till it is emtpy. What is the reasoning behind this approach? does it means that completions occurring while the handler is running cause interrupts which could be saved? is there any problem with first empty-ing the CQ and only then arming it? The latter approach is taken by iser code. As far as i understand it can not cause the ib consumer to miss interrupts, am i wrong? Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
