From: Jon Mason <jdmason@us.ibm.com>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Don Fry <brazilnut@us.ibm.com>, netdev@vger.kernel.org
Subject: Re: [RFT] pcnet32 NAPI changes
Date: Tue, 20 Jun 2006 11:05:04 -0500 [thread overview]
Message-ID: <20060620160504.GA3187@us.ibm.com> (raw)
In-Reply-To: <20060620144724.GL26952@csclub.uwaterloo.ca>
On Tue, Jun 20, 2006 at 10:48:07AM -0400, Lennart Sorensen wrote:
> On Tue, Jun 20, 2006 at 08:53:55AM -0500, Jon Mason wrote:
> > The amount of polls per received packet is very low, thus removing the
> > benefit of NAPI. A compile time option would allow those users who know
> > better to DTRT.
>
> Well I know on the slow poke system I run on, with the napi polling, the
> system can process packets, and get work done, and not fall over and die
> from handling interrupts. Without it, even 70Mbit of data on a single
> port will flood the system with packet overruns to the point the
> watchdog times out and the system reboots. So I don't know if polling
> is slightly more inefficient with little traffic, it is certainly a lot
> more efficient and safer when there is suddenly a lot more traffic.
> Maybe it should be a module option, so that you can pick what you want.
> Heck it could be a per port option even. :)
The point of my comment was CPU utilization.
It appears that a bug is trying to be fixed by adding NAPI. This
sounds a bit hackish to me, and could hide the root cause of the
problem. So I'm not sure that is the best idea, but I will defer to
the maintainer.
>
> > Yup, but the "everyone else is doing it" argument never worked with my
> > parents. All it takes is one brave soul to determine the reasoning
> > behind the magic numbers and convert them into #define's. Shouldn't be
> > more than one day's work.
>
> Is this a magic number in your opinion?
>
> lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */
>
> I guess one could do
> #define CSR0_RST 0x0001
> #define CSR0_STRT 0x0002
> #define CSR0_STOP 0x0004
> etc...
>
> and then
> lp->a.write_csr(ioaddr, 0, CSR0_STRT); /* Set STRT bit */
>
> Does that help? I am not sure. I think the comment behind it is
> plenty.
But your example is just one instance. Here is one without a comment:
lp->a.write_csr(ioaddr, 4, 0x0915);
What is it doing? Is it still needed? Can it be done anywhere else?
Who knows, because it is magic. The 4 can be defined as CSR0_STOP, per
your example above, but what does value 0x0915 do?
My point was that there are certain parts of the code which are
non-intuative and should be commented and there are others which a
good descrptive value would be nice.
>
> Len Sorensen
next prev parent reply other threads:[~2006-06-20 16:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-16 19:11 [RFT] pcnet32 NAPI changes Don Fry
2006-06-19 14:58 ` Lennart Sorensen
2006-06-19 20:41 ` Jon Mason
2006-06-19 20:49 ` Lennart Sorensen
2006-06-20 13:53 ` Jon Mason
2006-06-20 14:48 ` Lennart Sorensen
2006-06-20 16:05 ` Jon Mason [this message]
2006-06-20 18:10 ` Lennart Sorensen
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=20060620160504.GA3187@us.ibm.com \
--to=jdmason@us.ibm.com \
--cc=brazilnut@us.ibm.com \
--cc=lsorense@csclub.uwaterloo.ca \
--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.