Hi,
>You cannot turn it on/off. The driver may support this optional API
> or not. If it supports it, it's the driver sole decision when it's
> better to use polling/interrupt-per-packet according it its hardware
> specifics.
I doubt whether this is exactly so for all NICS, as one might
understand from your answer.
For example, with e1000 NICs, you can
select to build the driver with or without polling support.
See, while configuring the kernel:
Device Drivers->Network Device Support->Ethernet 1000 Mbit -> Intel
(R) PRO/1000
Gigabit Ethernet Support->Use RX polling (NAPI).
selecting it sets the CONFIG_E1000_NAPI to y.
By default, in newer kernels, for e1000, it comes with support for
NAPI by default,
but you can also build it without this support.
And if you will look at the code of the driver, you will find in e1000_main.c
module the following:
#ifdef CONFIG_E1000_NAPI
netdev->poll = &e1000_clean;
netdev->weight = 64;
#endif
Which means that , when building without CONFIG_E1000_NAPI set, you
will not have
the poll method and therefore no polling/NAPI.
You have also the ability to choose NAPI for other nics; for example,
Tulip; see
Device Drivers->Network Device Support->Ethernet 10 or 100 Mbit - "Tulip"
family network device support->Use NAPI RX polling.
It could be that on other NICs you cannot turn it on/off.
Broadcom was the first to release the tg3 driver with support for NAPI
for Linux. So they have probably a lot of experience with it, and
it could be that there NAPI support is built in and you cannot avoid it.
BTW, with Open Solaris, this is exactly the situation: the NAPI
support is in the core automatically; the driver start
as interrupt driver, and changes to polling when there is a high load
of interrupts.The drivers need not be built
with any NAPI special support. The driver binary is
the same when working with/without NAPI.There is a way, however, to configure
kernel-wide NAPI parameters.
Regards,
Rami Rosen
On Dec 18, 2007 10:14 PM, Oron Peled <[EMAIL PROTECTED]> wrote:
> On Tuesday, 18 בDecember 2007, Yedidyah Bar-David wrote:
> > I am not an expert on this, but what you want might be "NAPI" - a new
> > network driver infrastructure designed to solve just that. Google a bit
> > - I do not know exactly when it entered 2.6 (and you did not state your
> > kernel version) and which drivers use it already.
>
> 1. NAPI was new at kernel 2.3.x when it was developed towards 2.4
>
> 2. It gives the *driver* the option to toggle between interrupt driven
> and polling mode at runtime. E.g:
> - A GB ethernet at full speed may better poll the hardware every once
> in a while.
> - The same card is better off using interrupt driven mode if the
> trafic is low.
>
> 3. You cannot turn it on/off. The driver may support this optional API
> or not. If it supports it, it's the driver sole decision when it's
> better to use polling/interrupt-per-packet according it its hardware
> specifics.
>
> 4. I don't think a single fast ethernet card can severely affect your
> hardware interrupt load. So either:
> - You have a GB (or maybe 2GB?) ethernet with high load.
> - You have several fast-ethernet cards working at full speed.
>
> 5. A far better suspect would be the disk controller (e.g: working
> without DMA etc.)
>
> 6. Why guess?
> watch -n10 -d cat /proc/interrupts
> And calculate how many interrupts per-sec occured for various devices.
> That would give you a rough idea who are the possible suspects.
>
>
> --
> Oron Peled Voice/Fax: +972-4-8228492
> [EMAIL PROTECTED] http://www.actcom.co.il/~oron
> ICQ UIN: 16527398
>
> Linux lasts longer!
> -- "Kim J. Brand" <[EMAIL PROTECTED]>
>
>
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
>
