[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60C611E0.5020908@gmail.com>
Date: Sun, 13 Jun 2021 17:10:40 +0300
From: Nikolai Zhubr <zhubr.2@...il.com>
To: Arnd Bergmann <arnd@...nel.org>
CC: netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.
13.06.2021 1:41, Arnd Bergmann:
> Or, to keep the change simpler, keep the inner loop in the tx
> and rx processing, doing all rx events before moving on
> to processing all tx events, but then looping back to try both
> again, until either the budget runs out or no further events
> are pending.
Ok, made a new version: https://pastebin.com/3FUUrg7C
It is much simpler and is very close to your patch now.
All previous conditional defines are eliminated along with unnecessary
code fragments, and here is TUNE8139_BIG_LOOP to introduce a top-level
loop in poll function as you suggested above. But apparently it works
well both with and without this loop. At least my testing did not show
any substantial difference in performance. Therefore I think it could be
completely removed for the sake of simplicity.
One problem though is the kernel now always throws a traceback shortly
after communication start:
https://pastebin.com/VhwQ8wsU
According to system.map it likely points to __local_bh_endble_ip() and
there is one WARN_ON_ONCE() in it indeed, but I have no idea what it is
and how to fix it.
Yet another thing is that tp->rx_lock and tp->lock are now used within
poll function in a way that possibly suggests one of them could be
eliminated.
Thank you,
Regards,
Nikolai
>
> Arnd
>
Powered by blists - more mailing lists