From: Nikolai Zhubr <zhubr.2@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Heiner Kallweit <hkallweit1@gmail.com>, netdev <netdev@vger.kernel.org>
Subject: Re: Realtek 8139 problem on 486.
Date: Tue, 08 Jun 2021 02:07:59 +0300 [thread overview]
Message-ID: <60BEA6CF.9080500@gmail.com> (raw)
In-Reply-To: <CAK8P3a0iwVpU_inEVH9mwkMkBxrxbGsXAfeR9_bOYBaNP4Wx5g@mail.gmail.com>
Hi Arnd,
02.06.2021 12:12, Arnd Bergmann:
[...]
> I think the easiest workaround to address this reliably would be to move all
> the irq processing into the poll function. This way the interrupt is completely
> masked in the device until the poll handler finishes, and unmasking it
> while there
> are pending events would reliably trigger a new irq regardless of level or edge
> mode. Something like the untested change at https://pastebin.com/MhBJDt6Z .
> I don't know of other drivers that do it like this though, so I'm not
> sure if this causes a different set of problems.
I started applying your patch (trying to morph it a little bit so as to
shove in a minimally invasive manner into 4.14) and then noticed that it
probably won't work as intended. If I'm not mistaken this rx poll thing
is only active within kind of "rx bursts", so it is not guaranteed to be
continually running all the time when there is no or little rx input.
I'd suppose some new additional work/thread would have to be introduced
in order for such approach to be reliably implemented.
Meanwhile, beside the lost tx irq issue, I've apparently identified rx
overrun issue. According to tinymembench, the raw RAM performance of
this system is roughly around 15-30 Mbytes/s at best, so it is close to
100Mbit wire speed. Tracing NFS over UDP operation (client side) I've
found that of 2 full-sized incoming NFS/UDP packets the second one will
always be lost, approved by rapid increase of iface err counter. More
specifically, I've found that a couple of packets sized 1500+700 can
still be successfully accepted, but no way 1500+1500. Apparently 8139
has very little ram builtin so it needs that packets can go into main
ram fast enough. It appeared though that just adding rsize=1024 allows
NFS work quite well, with only ocasional small pauses. Also, apparenly
TCP/IP somehow recovers/autotunes iteself automatically, so it just
works fine. I suppose this overrun problem can not be fixed in a general
form (other than forcing a downgrade of link speed to 10 Mbit), as AFAIK
there are no provisions in ethernet to request e.g. extra delays between
packets. What might be usefull though is dropping some line to dmesg
suggesting to somehow limit the incoming flow. Such hint in dmesg would
have saved me quite some time.
Anyway, for now I got it working quite well (with a re-added busy loop
and rsize=1024). I'm going to look at the elcr_set_level_irq approach
later, but it looks quite complicated. If there is something else I can
test while at it, please let me know.
Thank you,
Regards,
Nikolai
>
> Arnd
>
next prev parent reply other threads:[~2021-06-07 22:58 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 14:08 Realtek 8139 problem on 486 Nikolai Zhubr
2021-05-29 18:42 ` Heiner Kallweit
2021-05-29 21:44 ` tedheadster
2021-05-30 0:49 ` Nikolai Zhubr
2021-05-30 10:36 ` Nikolai Zhubr
2021-05-30 17:27 ` Nikolai Zhubr
2021-05-30 20:54 ` Arnd Bergmann
2021-05-30 23:17 ` Nikolai Zhubr
2021-05-31 16:53 ` Nikolai Zhubr
2021-05-31 18:39 ` Arnd Bergmann
2021-05-31 22:18 ` Nikolai Zhubr
2021-05-31 22:30 ` Heiner Kallweit
2021-06-01 7:20 ` Arnd Bergmann
2021-06-01 10:53 ` Nikolai Zhubr
2021-06-01 11:42 ` Heiner Kallweit
2021-06-01 16:09 ` Nikolai Zhubr
2021-06-01 21:48 ` Heiner Kallweit
2021-06-01 23:37 ` Nikolai Zhubr
2021-06-02 9:12 ` Arnd Bergmann
2021-06-07 23:07 ` Nikolai Zhubr [this message]
2021-06-08 7:44 ` Arnd Bergmann
2021-06-08 20:32 ` Nikolai Zhubr
2021-06-08 20:45 ` Arnd Bergmann
2021-06-08 22:07 ` Nikolai Zhubr
2021-06-09 7:09 ` Arnd Bergmann
2021-06-12 17:40 ` Nikolai Zhubr
2021-06-12 22:41 ` Arnd Bergmann
2021-06-13 14:10 ` Nikolai Zhubr
2021-06-13 21:52 ` Arnd Bergmann
2021-06-03 18:32 ` Maciej W. Rozycki
2021-06-04 7:36 ` Arnd Bergmann
2021-06-20 0:34 ` Thomas Gleixner
2021-06-20 10:19 ` Arnd Bergmann
2021-06-21 4:10 ` Maciej W. Rozycki
2021-06-21 11:22 ` Arnd Bergmann
2021-06-21 14:42 ` Maciej W. Rozycki
2021-06-21 15:20 ` Arnd Bergmann
2021-06-22 11:12 ` David Laight
2021-06-22 12:42 ` Nikolai Zhubr
2021-06-22 13:22 ` Arnd Bergmann
2021-06-22 18:42 ` Nikolai Zhubr
2021-06-22 19:26 ` Arnd Bergmann
2021-06-23 1:04 ` Maciej W. Rozycki
2021-06-24 17:56 ` Nikolai Zhubr
2021-06-24 18:25 ` Maciej W. Rozycki
2021-07-14 23:32 ` Maciej W. Rozycki
2021-07-15 7:32 ` Nikolai Zhubr
2021-07-16 23:48 ` Maciej W. Rozycki
2021-06-23 16:31 ` Nikolai Zhubr
2021-06-23 23:39 ` Maciej W. Rozycki
2021-06-24 8:28 ` Arnd Bergmann
2021-07-02 19:02 ` Nikolai Zhubr
2021-07-03 9:10 ` Arnd Bergmann
2021-07-08 19:21 ` Nikolai Zhubr
2021-07-09 7:31 ` Arnd Bergmann
2021-07-09 12:43 ` David Laight
2021-06-01 17:44 ` Maciej W. Rozycki
2021-06-02 15:14 ` Nikolai Zhubr
2021-06-02 15:28 ` Arnd Bergmann
2021-05-31 19:05 ` Heiner Kallweit
2021-05-31 18:29 ` Denis Kirjanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60BEA6CF.9080500@gmail.com \
--to=zhubr.2@gmail.com \
--cc=arnd@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.