Maksim, The check_hang_subtask function is only meant to be run once every 2 seconds. As such you should only be seeing one interrupt per vector every 2 seconds. How is this overloading your CPU? Are you seeing the interrupts fire at a rate faster than 1 every 2 seconds?
The function is meant to trigger an interrupt every 2 seconds in the unlikely event that an interrupt is lost. Without it you may see Tx/Rx DMA hangs due to lost interrupts. Thanks, Alex On 02/04/2014 06:54 AM, Maksim M wrote: > Alexander, > Please, dismiss previous email, it seems, I got it sorted out. > According to the 82599, EICS Register enables sw to initiate a > hardware interrupt. Setting EICS bit causes interrupt assertion. > As you pointed, event service triggers ixgbe_check_hang_subtask(). It > calls ixgbe_irq_rearm_queues() that is really doing the job. > It overloads CPU in terms of interrupts, therefore in wire-speed rate > we see some performance degradation, but from INTEL side it looks > indispensable. > What side effect could it cause, disabling that interrupt generation > and what the reason to strobe interrupts lines? > > P.S Thanks again and sorry for disturbing! > Regards, Maksim > > > ------------------------------------------------------------------------ > From: maksim_m2...@hotmail.com > To: alexander.h.du...@intel.com > Subject: RE: ixgbe NAPI > Date: Tue, 4 Feb 2014 11:10:20 +0200 > > Alexander, > Thanks for reply. > We get interrupt(irq num) via request_irq(), providing irq handler. It > means that it would be generated by the hardware(as I was sure - > wrongly , after DMA transaction). Here attached file that depicts > interrupt picture of dna interface(it is same as ixgbe, in term of > interrupt scheme) -- no packets have been sent/received. All > interrupts are increased in the same rate. Also, the file contains > stack trace, sampled in IRQ Handler point. It seems, that hardware > initiates that interrupt. Looking at service event handler, I try to > understand how it could cause hardware to fire interrupt. > May be, I misunderstand some point :). > > P.S > Thanks again for assistance! > > Regards, Maksim > > > Date: Mon, 3 Feb 2014 09:39:30 -0800 > > From: alexander.h.du...@intel.com > > To: maksim_m2...@hotmail.com; E1000-devel@lists.sourceforge.net > > Subject: Re: ixgbe NAPI > > > > On 02/03/2014 08:59 AM, Maksim M wrote: > > > Hi, Alexander > > > > ------------------------------------------------------------------------ > > > > > > > > > Recently, I came across some issue with ixgbe drive. > > > The matter is following: > > > IXGBE is working in NAPI , so I was sure that Rx interrupt was > fired for > > > first packet in the batch and after that, it works in polling mode(as > > > every tutorial explains). That first interrupt delegates the job via > > > napi_schedule() to the sofrirq to make polling. But as turned out, > > > interrupts is coming without being dependent whether traffic exist or > > > not. Polling method is constantly being called by softirq when cpu is > > > idle. Trying to debug the issue I see that interrupt is called every > > > time even there are no packets(interface is up but no physical > > > connection). I tried to check EICR, and the bit responsible for > > > particular queue is constantly high. I could not understand what > causes > > > rx/tx interrupts. Tried to play with throttle rate(EITR), but even > it is > > > set to zero it still fires interrupt. > > > > > > P.S > > > Sorry to bother and thanks in advance. > > > > > > Regards, Maksim > > > > Maksim, > > > > In order to guarantee the interrupts continue to fire, even in the case > > of a dropped interrupt the service event handler also triggers an > > interrupt every 2 seconds in addition to checking for a hung Tx ring. > > If you check there should be code writing to the EICS register in the > > service tast that is triggering the interrupts you are seeing. > > > > Thanks, > > > > Alex ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
