From: Jeff Garzik <jgarzik@pobox.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Netdev <netdev@oss.sgi.com>, Ayaz Abdulla <AAbdulla@nvidia.com>
Subject: Re: [patch] forcedeth: add support for interrupt mitigation
Date: Fri, 21 Oct 2005 17:33:14 -0400 [thread overview]
Message-ID: <43595E9A.7090505@pobox.com> (raw)
In-Reply-To: <43592FE5.20106@colorfullife.com>
Manfred Spraul wrote:
> Hi,
>
> The current forcedeth driver doesn't support interrupt mitigation, this
> can result in an incredible number of interrupts/sec for gigabit links.
> The attached patch adds a throughput mode that enables an interrupt
> mitigation scheme.
>
>
> --
> Manfred
>
>
> ------------------------------------------------------------------------
>
> --- 2.6/drivers/net/forcedeth.c 2005-10-20 23:17:24.000000000 +0200
> +++ build-2.6/drivers/net/forcedeth.c 2005-10-19 21:01:55.000000000 +0200
> @@ -98,6 +98,7 @@
> * 0.43: 10 Aug 2005: Add support for tx checksum.
> * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation.
> * 0.45: 18 Sep 2005: Remove nv_stop/start_rx from every link check
> + * 0.46: 20 Aug 2005: Add irq optimization modes.
> *
> * Known bugs:
> * We suspect that on some hardware no TX done interrupts are generated.
> @@ -109,7 +110,7 @@
> * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
> * superfluous timer interrupts from the nic.
> */
> -#define FORCEDETH_VERSION "0.45"
> +#define FORCEDETH_VERSION "0.46"
> #define DRV_NAME "forcedeth"
>
> #include <linux/module.h>
> @@ -164,7 +165,8 @@
> #define NVREG_IRQ_LINK 0x0040
> #define NVREG_IRQ_TX_ERROR 0x0080
> #define NVREG_IRQ_TX1 0x0100
> -#define NVREG_IRQMASK_WANTED 0x00df
> +#define NVREG_IRQMASK_THROUGHPUT 0x00df
> +#define NVREG_IRQMASK_CPU 0x0040
>
> #define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \
> NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \
> @@ -178,7 +180,8 @@
> * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms
> */
> NvRegPollingInterval = 0x00c,
> -#define NVREG_POLL_DEFAULT 970
> +#define NVREG_POLL_DEFAULT_THROUGHPUT 970
> +#define NVREG_POLL_DEFAULT_CPU 13
> NvRegMisc1 = 0x080,
> #define NVREG_MISC1_HD 0x02
> #define NVREG_MISC1_FORCE 0x3b0f3c
> @@ -539,6 +542,18 @@
> */
> static int max_interrupt_work = 5;
>
> +/*
> + * Optimization can be either throuput mode or cpu mode
> + */
> +#define NV_OPTIMIZATION_MODE_THROUGHPUT 0
> +#define NV_OPTIMIZATION_MODE_CPU 1
> +static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;
> +
> +/*
> + * Poll interval for timer irq
> + */
> +static int poll_interval = -1;
The code changes themselves seem correct, but this patch suffers from a
few overall problems.
* "throughput or cpu" doesn't tell the user very much -- or me, for that
matter. Does "cpu mode" mean low latency, high interrupt count? If so,
just allow the user to choose between throughput and latency.
* making this a static decision at module load time is sub-optimal. 99%
of users will simply use the default. the option should be
per-interface, ideally. controlled by ethtool?
* there is zero information on how to use poll interval. again, 99% of
users will simply use the default. since the poll interval is written
directly to a hardware register, you should give the user some idea of
the unit of measure (ms? ticks? bus cycles? ns?), and some idea of min/max.
next prev parent reply other threads:[~2005-10-21 21:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-21 18:13 [patch] forcedeth: add support for interrupt mitigation Manfred Spraul
2005-10-21 20:29 ` Francois Romieu
2005-10-21 20:42 ` John W. Linville
2005-10-21 21:07 ` Jeff Garzik
2005-10-21 21:33 ` Jeff Garzik [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-10-21 21:10 Ayaz Abdulla
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=43595E9A.7090505@pobox.com \
--to=jgarzik@pobox.com \
--cc=AAbdulla@nvidia.com \
--cc=manfred@colorfullife.com \
--cc=netdev@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).