From: Matthew Garrett <mjg59@srcf•ucam.org>
To: Arjan van de Ven <arjan@infradead•org>
Cc: linux-kernel@vger•kernel.org, netdev@vger•kernel.org
Subject: Re: Network drivers that don't suspend on interface down
Date: Wed, 20 Dec 2006 14:31:35 +0000 [thread overview]
Message-ID: <20061220143134.GA25462@srcf.ucam.org> (raw)
In-Reply-To: <1166621931.3365.1384.camel@laptopd505.fenrus.org>
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@srcf•ucam.org
next prev parent reply other threads:[~2006-12-20 14:31 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061219185223.GA13256@srcf.ucam.org>
[not found] ` <200612191959.43019.david-b@pacbell.net>
[not found] ` <20061220042648.GA19814@srcf.ucam.org>
[not found] ` <200612192114.49920.david-b@pacbell.net>
[not found] ` <20061220053417.GA29877@suse.de>
[not found] ` <20061220055209.GA20483@srcf.ucam.org>
[not found] ` <1166601025.3365.1345.camel@laptopd505.fenrus.org>
2006-12-20 12:53 ` Network drivers that don't suspend on interface down Matthew Garrett
2006-12-20 13:38 ` Arjan van de Ven
2006-12-20 14:31 ` Matthew Garrett [this message]
2006-12-20 15:51 ` Arjan van de Ven
2006-12-20 22:49 ` Stephen Hemminger
2006-12-20 23:37 ` Rick Jones
2006-12-19 23:51 ` Stephen Hemminger
2006-12-21 0:11 ` Francois Romieu
2006-12-20 0:26 ` Stephen Hemminger
2006-12-21 11:18 ` Francois Romieu
2006-12-21 1:12 ` Matthew Garrett
2006-12-21 2:05 ` Michael Wu
2006-12-21 2:18 ` Matthew Garrett
2006-12-21 2:38 ` Daniel Drake
2006-12-21 2:45 ` Matthew Garrett
2006-12-21 3:08 ` Daniel Drake
2006-12-21 3:25 ` Matthew Garrett
2006-12-21 3:37 ` Dan Williams
2006-12-21 3:29 ` Dan Williams
2006-12-21 3:14 ` Dan Williams
2006-12-21 13:14 ` jamal
2006-12-21 2:29 ` Daniel Drake
2006-12-21 2:10 ` Jesse Brandeburg
2006-12-21 8:54 ` Arjan van de Ven
2006-12-22 1:03 ` Herbert Xu
2006-12-23 8:54 ` Pavel Machek
2006-12-20 15:27 ` Olivier Galibert
2006-12-20 15:34 ` Arjan van de Ven
2006-12-20 16:40 ` Olivier Galibert
2006-12-20 17:21 ` Arjan van de Ven
2006-12-20 20:40 ` Benny Amorsen
2006-12-20 21:49 ` Arjan van de Ven
2006-12-20 21:15 ` Stefan Rompf
2006-12-20 14:00 ` Jiri Benc
2006-12-20 18:12 ` Dan Williams
2006-12-21 1:15 ` Matthew Garrett
2006-12-21 1:57 ` Michael Wu
2006-12-21 2:20 ` Matthew Garrett
2006-12-21 3:02 ` Dan Williams
2006-12-21 3:06 ` Dan Williams
2006-12-21 3:14 ` Matthew Garrett
2006-12-21 3:32 ` Dan Williams
2006-12-21 13:19 ` Sven-Haegar Koch
2006-12-21 17:16 ` Dan Williams
2006-12-21 18:27 ` Valdis.Kletnieks
2006-12-22 1:25 ` Matt Domsch
2006-12-20 16:04 ` Maciej W. Rozycki
2006-12-21 5:25 David Brownell
2006-12-21 7:08 ` Stephen Hemminger
2006-12-21 8:11 ` David Brownell
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=20061220143134.GA25462@srcf.ucam.org \
--to=mjg59@srcf$(echo .)ucam.org \
--cc=arjan@infradead$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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