[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0Wry54wUGpdRnet3WAx1yfd-RiAgXvmTdPd1aCTTSsFw@mail.gmail.com>
Date: Tue, 8 Jun 2021 22:45:55 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Nikolai Zhubr <zhubr.2@...il.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.
On Tue, Jun 8, 2021 at 10:32 PM Nikolai Zhubr <zhubr.2@...il.com> wrote:
>
> 08.06.2021 10:44, Arnd Bergmann:
> [...]
> > However, it should not lead to any missed interrupts with my patch:
> > at any point in time, you have either all hardware interrupts enabled,
> > or you are in napi polling mode and are guaranteed to call the poll
>
> For this to work, napi_complete should likely be called with some
> different condition instead?
> E.g.:
>
> - if (work_done < budget) {
> + if ((work_done < budget) && !status) {
>
> Otherwise polling would possibly be shut down before all non-rx events
> are cleared?
> For some reason such 'corrected' version does not work here though
> (Communication fails completely). Probably I'm still missing something.
The idea was that all non-rx events that were pending at the start of the
function have been Acked at this point, by writing to the IntrMask
register before processing the particular event. If the same kind of event
arrives after the Ack, then opening in the mask should immediately trigger
the interrupt handler, which reactivates the poll function.
If you instead want to re-arm the poll function every time that 'status'
was non-zero, you would have to also return 'budget' to the caller, like
+ if (status)
+ work_done = budget; /* pretend RX is still busy */
if (work_done < budget) {
I think that should also work, but it seems more expensive since it would
always go back into the poll function after a non-RX event, rather than
only going back into the irq handler if a new event has just arrived.
Arnd
Powered by blists - more mailing lists