linux-kernel - Re: [PATCH net-next 6/8] net: thunderx: Rework interrupt handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 30 Aug 2015 22:01:04 +0530
From:	Sunil Kovvuri <sunil.kovvuri@...il.com>
To:	Aleksey Makarov <feumilieu@...il.com>
Cc:	Alexey Klimov <klimov.linux@...il.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Robert Richter <rric@...nel.org>,
	David Daney <david.daney@...ium.com>,
	Sunil Goutham <Sunil.Goutham@...iumnetworks.com>,
	Aleksey Makarov <aleksey.makarov@...iumnetworks.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Robert Richter <robert.richter@...iumnetworks.com>,
	Sunil Goutham <sgoutham@...ium.com>,
	LAKML <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH net-next 6/8] net: thunderx: Rework interrupt handler

On Sun, Aug 30, 2015 at 2:50 PM, Aleksey Makarov <feumilieu@...il.com> wrote:
> On 29.08.2015 04:44, Alexey Klimov wrote:
>
>>> -static irqreturn_t nicvf_intr_handler(int irq, void *nicvf_irq)
>>> +static irqreturn_t nicvf_intr_handler(int irq, void *cq_irq)
>>> +{
>>> +       struct nicvf_cq_poll *cq_poll = (struct nicvf_cq_poll *)cq_irq;
>>> +       struct nicvf *nic = cq_poll->nicvf;
>>> +       int qidx = cq_poll->cq_idx;
>>> +
>>> +       nicvf_dump_intr_status(nic);
>>> +
>>> +       /* Disable interrupts */
>>> +       nicvf_disable_intr(nic, NICVF_INTR_CQ, qidx);
>>> +
>>> +       /* Schedule NAPI */
>>> +       napi_schedule(&cq_poll->napi);
>>> +
>>> +       /* Clear interrupt */
>>> +       nicvf_clear_intr(nic, NICVF_INTR_CQ, qidx);
>>> +
>>> +       return IRQ_HANDLED;
>>> +}
>>
>>
>> You're not considering spurious irqs in all new irq handlers here and
>> below and schedule napi/tasklets unconditionally. Is it correct?
>> For me it looks like previous implementation relied on reading of
>> NIC_VF_INT to understand irq type and what actions should be
>> performed. It generally had idea that no interrupt might occur.
>
>
> 1. The previous version of the handler did not handle spurious interrupts
> either.  Probably that means that the author of the patch knows for sure
> that they do not happen.

Yes, no spurious interrupts are expected from hardware.
Even if it does the NAPI poll routine will handle it as valid
descriptor count would be zero.
Don't think it makes sense to check for spurious interrupt upon every interrupt.

>
> 2. Instead of reading the status register new version registers different
> handlers for different irqs.  I don't see why it can be wrong.

Previous implementation results on scheduling multiple NAPI poll handlers
on the same CPU even if IRQ's affinities are set to different CPUs.
Hence they are seperated now.

>
> I am going to address your other suggestions in the next version of the
> patchset.
>
> Thank you
> Aleksey Makarov
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/