Re: [E1000-devel] ixgbe NAPI

[Alexander D. <ale...@in...>]

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: mak...@ho...
> To: ale...@in...
> 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: ale...@in...
> > To: mak...@ho...; E10...@li...
> > 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