[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKFLimKTzseP34wyZ+SyASG6-2Zn=KF611PY=LO23pJLq4nNg@mail.gmail.com>
Date: Tue, 25 Sep 2018 19:14:54 -0700
From: Michael Chan <michael.chan@...adcom.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Song Liu <songliubraving@...com>,
Eric Dumazet <edumazet@...gle.com>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@...adcom.com> wrote:
>
> On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> >
> > It seems bnx2 should have a similar issue ?
> >
>
> Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> that MSIX will only assert once after it is ARMed. If we return from
> ->poll() when budget of 0 is reached without ARMing, we may not get
> another MSIX.
>
On second thought, I think bnx2 is ok. If netpoll is polling on the
TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
register is untouched. bnx2 uses the status block for events and the
producers/consumers are cumulative. So there is no need to ACK the
status block unless ARMing for interrupts. If there is an IRQ about
to be fired, it won't be affected by the polling done by netpoll.
In the case of bnxt, a completion ring is used for the events. The
polling done by netpoll will cause the completion ring to be ACKed as
entries are processed. ACKing the completion ring without ARMing may
cause future IRQs to be disabled for that ring.
Powered by blists - more mailing lists