Message-ID: <20061220143134.GA25462@srcf.ucam.org>
Date:	Wed, 20 Dec 2006 14:31:35 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down

On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> about your driver list;
> do you have an idea of what the top 5 relevant ones would be?
> I'd be surprised if the top 5 together had less than 95% market share,
> so if we fix those we'd be mostly done already.

In terms of what I've seen on vaguely modern hardware, I'd guess at 
e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, 
with via-rhine appearing at the very low end. I'll try to grep through 
our hardware database results to get a stronger idea about percentages.

> > The situation is more complicated for wireless. Userspace expects to be 
> > able to get scan results from the card even if the interface is down.
> 
> if it's down userspace cannot currently expect this (if it does it's
> broken), just as it currently can't expect link notifications when the
> interface is down. It needs to have the interface up for this. 
> (but point taken for a 3rd state)

The documentation for what userspace can legitimately expect of the 
kernel is distinctly lacking, and as far as I can tell most of the 
common drivers support scanning while the interface is down. It would be 
immensely helpful if we could have a better idea of which kernel 
behaviour is deliberate, and which bits of kernel functionality are 
accidental and might go away at any time. Right now, I have various 
scripts depending on this behaviour because there's absolutely no 
indication that I'm not supposed to be.

(Of course, I may have missed it somewhere - I've never been able to 
find terribly comprehensive documentation on WE)

> so what do you want from this 3rd state? rough guess based on what I
> think the desktop wants (so please correct/append)

Just to be clear: in this world view, "down" maps to "fully powered 
down", so this third state is a "low power consumption mode"? If so:

> In the third state you 
> * don't expect to get or send "regular" packets
> * don't have a dhcp lease or anything like that
> * you do expect to get link change notification [1]
> * you do expect to be able to scan for access points [2]

Yes, I think that's a fair summary. 

> open questions
> * what if you get a WOL event?

In an ideal world, I think the information would be passed to userspace 
and it would get to make the distinction. I appreciate that the hardware 
may have different ideas about what's appropriate...

> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll every X seconds, then after an hour, every minute etc.

Yeah, I guess that's a problem. From a user perspective, the 
functionality is only really useful if the latency is very small. I 
think where possible we'd want to power down the chip while keeping the 
phy up, but it would be nice to know how much power that would actually 
cost us.

(We have a similar issue when it comes to stuff like monitor hotplug - 
it's the sort of thing that many users are willing to accept losing some 
battery for, and there probably isn't a single right answer)
 
> [2] would it be permissible to temporarily power up the device on scan?
> Eg how frequently does the desktop expect to poll for scanning, and what
> kind of latency would be tolerable?

network-manager's behaviour when the interface is inactive is to scan 
every 2 minutes. I don't think latency is too much of an issue.

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists