All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: akpm@osdl.org, netdev@vger.kernel.org,
	James K Lewis <jklewis@us.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Jens Osterkamp <Jens.Osterkamp@de.ibm.com>,
	Jeff Garzik <jgarzik@pobox.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [RFC] HOWTO use NAPI to reduce TX interrupts
Date: Sat, 19 Aug 2006 13:25:18 +0200	[thread overview]
Message-ID: <200608191325.19557.arnd@arndb.de> (raw)
In-Reply-To: <44E7BB7F.7030204@osdl.org>

On Sunday 20 August 2006 03:31, Stephen Hemminger wrote:
>=20
> The reason reclaim via poll() is efficient is because it avoid causing a=
=20
> softirq that is
> necessary when skb_free_irq() is done. Instead it reuses the softirq=20
> from the poll() routine.=20

Ok, I completely missed this point so far, thanks for the info.

> Like all Rx NAPI, using poll() for reclaim means:=20
> =A0 =A0 + aggregating multiple frames in one irq
> =A0 =A0 - increased overhead of twiddling with the IRQ mask
> =A0 =A0 - more ways to get driver stuck

What is the best way to treat the IRQ mask for TX interrupts?
I guess it should be roughly:

=2D off when we expect ->poll() to be called, i.e. after calling
  netif_rx_schedule() or returning after a partial rx from poll().
=2D off when there are no packets left in the TX queue
=2D on while RX interrupts are on and we're waiting for packets
  to be transmitted.

> Some drivers do all their irq work in the poll() routine (including PHY=20
> handling).
> This is good if reading the IRQ status does an auto mask operation.
>=20
> The whole NAPI documentation area is a mess and needs a good writer
> to do some major restructuring. It should also be split into reference=20
> information,
> tutorial and guide sections.

I won't be able to do that work, I'm neither a good writer nor a networking
person.

Do you think we should still merge a section like the text I wrote up, even
if it makes the text even less well structured? Should I maybe add it
somewhere else than the appendix?

	Arnd <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: linuxppc-dev@ozlabs.org, akpm@osdl.org,
	James K Lewis <jklewis@us.ibm.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Jeff Garzik <jgarzik@pobox.com>,
	Jens Osterkamp <Jens.Osterkamp@de.ibm.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [RFC] HOWTO use NAPI to reduce TX interrupts
Date: Sat, 19 Aug 2006 13:25:18 +0200	[thread overview]
Message-ID: <200608191325.19557.arnd@arndb.de> (raw)
In-Reply-To: <44E7BB7F.7030204@osdl.org>

On Sunday 20 August 2006 03:31, Stephen Hemminger wrote:
> 
> The reason reclaim via poll() is efficient is because it avoid causing a 
> softirq that is
> necessary when skb_free_irq() is done. Instead it reuses the softirq 
> from the poll() routine. 

Ok, I completely missed this point so far, thanks for the info.

> Like all Rx NAPI, using poll() for reclaim means: 
>     + aggregating multiple frames in one irq
>     - increased overhead of twiddling with the IRQ mask
>     - more ways to get driver stuck

What is the best way to treat the IRQ mask for TX interrupts?
I guess it should be roughly:

- off when we expect ->poll() to be called, i.e. after calling
  netif_rx_schedule() or returning after a partial rx from poll().
- off when there are no packets left in the TX queue
- on while RX interrupts are on and we're waiting for packets
  to be transmitted.

> Some drivers do all their irq work in the poll() routine (including PHY 
> handling).
> This is good if reading the IRQ status does an auto mask operation.
> 
> The whole NAPI documentation area is a mess and needs a good writer
> to do some major restructuring. It should also be split into reference 
> information,
> tutorial and guide sections.

I won't be able to do that work, I'm neither a good writer nor a networking
person.

Do you think we should still merge a section like the text I wrote up, even
if it makes the text even less well structured? Should I maybe add it
somewhere else than the appendix?

	Arnd <><

  reply	other threads:[~2006-08-19 11:26 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-18 22:07 [PATCH 0/6]: powerpc/cell spidernet ethernet driver update Linas Vepstas
2006-08-18 22:07 ` Linas Vepstas
2006-08-18 22:20 ` [PATCH 1/6]: powerpc/cell spidernet burst alignment patch Linas Vepstas
2006-08-18 22:51   ` Arnd Bergmann
2006-08-18 22:51     ` Arnd Bergmann
2006-08-18 22:21 ` [PATCH 2/6]: powerpc/cell spidernet low watermark patch Linas Vepstas
2006-08-18 23:09   ` Arnd Bergmann
2006-08-18 23:09     ` Arnd Bergmann
2006-08-20  6:31     ` Benjamin Herrenschmidt
2006-08-20  6:31       ` Benjamin Herrenschmidt
2006-08-20 10:03       ` Arnd Bergmann
2006-08-20 10:03         ` Arnd Bergmann
2006-08-23 21:36         ` Linas Vepstas
2006-08-23 21:36           ` Linas Vepstas
2006-08-23 22:03           ` David Miller
2006-08-23 22:03             ` David Miller
2006-08-18 22:23 ` [PATCH 3/6]: powerpc/cell spidernet stop error printing patch Linas Vepstas
2006-08-18 22:25 ` [PATCH 4/6]: powerpc/cell spidernet ethtool -i version number info Linas Vepstas
2006-08-18 22:56   ` Arnd Bergmann
2006-08-18 22:56     ` Arnd Bergmann
2006-08-18 22:26 ` [PATCH 5/6]: powerpc/cell spidernet bottom half Linas Vepstas
2006-08-18 23:03   ` Arnd Bergmann
2006-08-18 23:03     ` Arnd Bergmann
2006-08-19  0:56     ` [RFC] HOWTO use NAPI to reduce TX interrupts Arnd Bergmann
2006-08-19  0:56       ` Arnd Bergmann
2006-08-20  1:31       ` Stephen Hemminger
2006-08-20  1:31         ` Stephen Hemminger
2006-08-19 11:25         ` Arnd Bergmann [this message]
2006-08-19 11:25           ` Arnd Bergmann
2006-08-20 17:48           ` [RFC v2] " Arnd Bergmann
2006-08-20 17:48             ` Arnd Bergmann
2006-08-21 20:40             ` NAPI documentation Stephen Hemminger
2006-08-21 20:40               ` Stephen Hemminger
2006-08-21 22:05               ` David Miller
2006-08-21 22:05                 ` David Miller
2006-08-21 22:09                 ` Stephen Hemminger
2006-08-21 22:09                   ` Stephen Hemminger
2006-08-21 22:17                   ` David Miller
2006-08-21 22:17                     ` David Miller
2006-08-21 23:52           ` [RFC] HOWTO use NAPI to reduce TX interrupts Linas Vepstas
2006-08-21 23:52             ` Linas Vepstas
2006-08-21 23:56             ` David Miller
2006-08-21 23:56               ` David Miller
2006-08-22  0:29               ` Roland Dreier
2006-08-22  0:29                 ` Roland Dreier
2006-08-22  0:32                 ` David Miller
2006-08-22  0:32                   ` David Miller
2006-08-23  1:29                   ` Shirley Ma
2006-08-23  1:29                     ` Shirley Ma
2006-08-23 21:52     ` [PATCH 5/6]: powerpc/cell spidernet bottom half Linas Vepstas
2006-08-23 21:52       ` Linas Vepstas
2006-08-18 22:29 ` [PATCH 6/6]: powerpc/cell spidernet refine locking Linas Vepstas

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=200608191325.19557.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Jens.Osterkamp@de.ibm.com \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=jgarzik@pobox.com \
    --cc=jklewis@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.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.