netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Network development list <netdev@vger.kernel.org>
Subject: Re: Runtime power management for network interfaces
Date: Tue, 1 Aug 2006 08:53:12 -0700	[thread overview]
Message-ID: <20060801085312.7b418961@localhost> (raw)
In-Reply-To: <200607311729.41890.david-b@pacbell.net>

On Mon, 31 Jul 2006 17:29:41 -0700
David Brownell <david-b@pacbell.net> wrote:

> On Monday 31 July 2006 9:17 am, Stephen Hemminger wrote:
> > On Tue, 25 Jul 2006 11:59:52 -0400 (EDT)
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > > During a Power Management session at the Ottawa Linux Symposium,
> > > it was generally agreed that network interface drivers ought to
> > > automatically suspend their devices (if possible) whenever:
> > > 
> > >     (1) The interface is ifconfig'ed down, or
> > > 
> > >     (2) No link is available.
> > 
> > This is hard because most of the power may be consumed by the PHY
> > interface and it needs to be alive to see link.
> 
> True only for #2, yes?  I think #1 could be adopted pretty widely, but
> no driver I've yet come across implements that policy.  I think maybe
> Don Becker didn't have power management on the brain nearly
> enough.  :)
> 
> 
> > > Has any progress been made in this direction?  If not, a natural
> > > approach would be to start with a reference implementation in one
> > > driver which could then be copied to other drivers.
> > > 
> > 
> > The problem is not generic, it really is specific to each device.
> 
> For #2, yes.  Much less so for #1; if the hardware has a low power
> mode, there's no point in being in any other mode when the interface
> is down.
> 
> This might actually be a good time to start rethinking power
> management for network interfaces.  Upcoming kernels (see the MM
> tree) have new class methods for suspend() and resume(), with the
> notion that they should be offloading tasks from drivers.  For
> network links, that would most naturally be netif_device_detach() on
> suspend, etc; if netdevices were to provide suspend() and resume()
> methods, those could be called via class suspend/resume as well as
> when they're configured down/up.  Just an idea of course ... but it
> might well be possible that some changes like that would be a nice
> incremental power savings on many systems, while simplifying some
> tasks that often confuse driver writers.

The tg3 and sky2 drivers both do power saving when not up.
It doesn't need special generic support. Just don't bring chip
up if the interface is config'd down.

> 
> > We have all the necessary infrastructure to do the right thing in
> > the network device driver, but in many cases we don't have the code
> > or the technical information to do proper power management.
> 
> I think that's more true for wakeup events than for PM in general.
> After all, quite a lot of network drivers do have suspend() methods
> that do something even if it's just going into PCI_D3, and resume()
> methods that are fully capable of re-initializing from power-off.
> 
> - Dave
> 

  reply	other threads:[~2006-08-01 15:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25 15:59 Runtime power management for network interfaces Alan Stern
2006-07-25 16:20 ` Auke Kok
2006-07-31  3:06   ` Randy.Dunlap
2006-07-31 16:19     ` Auke Kok
2006-07-25 17:03 ` David Brownell
2006-07-31 16:17 ` Stephen Hemminger
2006-08-01  0:29   ` David Brownell
2006-08-01 15:53     ` Stephen Hemminger [this message]
2006-08-01 15:18   ` Lennert Buytenhek

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=20060801085312.7b418961@localhost \
    --to=shemminger@osdl.org \
    --cc=david-b@pacbell.net \
    --cc=netdev@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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).