Runtime power management for network interfaces

Runtime power management for network interfaces

[Alan Stern]

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.

Presumably (1) should be easy enough to implement.  (2) might or might not
be feasible, depending on how much WOL support is available.  (It might
not be feasible at all for wireless networking.)  Still, there can be no
question that it would be a Good Thing for laptops to power-down their
ethernet controllers when the network cable is unplugged.

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.

Any suggestions?

Alan Stern

Re: Runtime power management for network interfaces

[Auke Kok]

Alan Stern 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.
> 
> Presumably (1) should be easy enough to implement.  (2) might or might not
> be feasible, depending on how much WOL support is available.  (It might
> not be feasible at all for wireless networking.)  Still, there can be no
> question that it would be a Good Thing for laptops to power-down their
> ethernet controllers when the network cable is unplugged.
> 
> 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.


Intel's newer e1000's (ich7 onboard e1000 and newer versions for instance) 
already support this feature partially - the MAC stays on but the PHY can be 
powered off when no link is present.

In order to enable this feature you will need to turn it on explicitly at load 
time:

modprobe e1000 SmartPowerDownEnable=1

Allthough not the entire NIC is powered off, it still saves a significant part 
of the power consumed by the NIC. All bits help. The power automatically 
restores once a cable is plugged in.


Cheers,

Auke

Re: Runtime power management for network interfaces

[Randy.Dunlap]

On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote:

> Alan Stern 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.
> > 
> > Presumably (1) should be easy enough to implement.  (2) might or might not
> > be feasible, depending on how much WOL support is available.  (It might
> > not be feasible at all for wireless networking.)  Still, there can be no
> > question that it would be a Good Thing for laptops to power-down their
> > ethernet controllers when the network cable is unplugged.
> > 
> > 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.
> 
> 
> Intel's newer e1000's (ich7 onboard e1000 and newer versions for instance) 
> already support this feature partially - the MAC stays on but the PHY can be 
> powered off when no link is present.
> 
> In order to enable this feature you will need to turn it on explicitly at load 
> time:
> 
> modprobe e1000 SmartPowerDownEnable=1

Please add that to Documentation/networking/e1000.txt.


> Allthough not the entire NIC is powered off, it still saves a significant part 
> of the power consumed by the NIC. All bits help. The power automatically 
> restores once a cable is plugged in.


---
~Randy

Re: Runtime power management for network interfaces

[Auke Kok]

Randy.Dunlap wrote:
> On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote:
> 
>> Alan Stern 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.
>>>
>>> Presumably (1) should be easy enough to implement.  (2) might or might not
>>> be feasible, depending on how much WOL support is available.  (It might
>>> not be feasible at all for wireless networking.)  Still, there can be no
>>> question that it would be a Good Thing for laptops to power-down their
>>> ethernet controllers when the network cable is unplugged.
>>>
>>> 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.
>>
>> Intel's newer e1000's (ich7 onboard e1000 and newer versions for instance) 
>> already support this feature partially - the MAC stays on but the PHY can be 
>> powered off when no link is present.
>>
>> In order to enable this feature you will need to turn it on explicitly at load 
>> time:
>>
>> modprobe e1000 SmartPowerDownEnable=1
> 
> Please add that to Documentation/networking/e1000.txt.

I'm long overdue with documentation updates ATM, I'll see if I can fix that :)

Cheers,

Auke

Re: Runtime power management for network interfaces

[David Brownell]

On Tuesday 25 July 2006 8:59 am, Alan Stern 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.
> 
> Presumably (1) should be easy enough to implement.

I can't imagine that there are many network drivers that couldn't
put the hardware in some kind of low power mode at that point.

All PCI drivers can certainly set_pci_power_state(pdev, PCI_D3hot)
and save a certain amount of power.  Of course, that means coping
with a possible device reset when going to PCI_D0, and I can imagine
some devices might prefer to use PCI_D2 rather than reload firmware.

Embedded chips probably have an easier time with this; just turn
off all the clocks going to that controller and its PHY.  


> (2) might or might not 
> be feasible, depending on how much WOL support is available.

A network adapter without PHY support in the WOL hardware wouldn't be
able to implement (2).  And in today's systems, where we can't rely on
ACPI+PCI to morph PME# to pci_driver.resume() during runtime suspend,
not all platforms can implement (2).  Embedded chips probably have an
easier time here ... I know for a fact that at91_ether can do that sort
of thing easily, at least on boards where the PHY IRQ is hooked up, so
that the driver doesn't need to poll link status.

The USB analogy here is that _some_ external transceivers (PHY) can
report link state changes via IRQs, supporting a mode where everything
else is powered off until the link can be active, at which point the
controller can come out of its low power state.  Those are of course
transceivers intended for use in systems with itty bitty batteries.


(I keep thinking wakeup event handling is pretty weak in Linux today.
As you know, we're still shaking the USB HCDs into shape there, since
some system configs have issues.  Network adapters seem to be another
major use case for wakeup events in Linux, and I get the impression
they're not as widely used -- or functional -- as would be good.)


> (It might 
> not be feasible at all for wireless networking.)  Still, there can be no
> question that it would be a Good Thing for laptops to power-down their
> ethernet controllers when the network cable is unplugged.
> 
> 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.
> 
> Any suggestions?

My initial thought was that network drivers could be refactored so
that they have ifsuspend() and ifresume() methods to put the hardware
into the low power state.

The remove(), open() and resume() methods would call ifresume(); probe(),
close() and suspend() would call ifsuspend() ... thatid give (1).  And
for hardware supporting (2) there'd be some housekeeping for the WOL support
during suspend() and resume(), in addition to netif_device_{de,at}tach().

For hardware where a PHY can report link state without requiring an active
Ethernet controller (e.g. at91_ether for sure) some events could trigger
ifresume()/ifsuspend() when the interface is active.

- Dave

Re: Runtime power management for network interfaces

[Stephen Hemminger]

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.

> 
> Presumably (1) should be easy enough to implement.  (2) might or might not
> be feasible, depending on how much WOL support is available.  (It might
> not be feasible at all for wireless networking.)  Still, there can be no
> question that it would be a Good Thing for laptops to power-down their
> ethernet controllers when the network cable is unplugged.
> 
> 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.
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.

-- 
Stephen Hemminger <shemminger@osdl.org>
"And in the Packet there writ down that doome"

Re: Runtime power management for network interfaces

[David Brownell]

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.


> 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

Re: Runtime power management for network interfaces

[Stephen Hemminger]

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
> 

Re: Runtime power management for network interfaces

[Lennert Buytenhek]

On Mon, Jul 31, 2006 at 09:17:28AM -0700, Stephen Hemminger 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.

At least some Davicom PHYs (IIRC) have an 'energy detect' bit, which
allows you to very quickly see whether there is a link partner without
waiting for autonegotiation to complete.

So, you could just power on the PHY only once every couple of seconds,
and instantly power it down again if the 'energy detect' bit doesn't go
on within some short time interval.


cheers,
Lennert