From: Stefan Rompf <srompf@isg.de>
To: jamal <hadi@cyberus.ca>
Cc: netdev@oss.sgi.com
Subject: Re: Patch: Device operative state notification against 2.5.7
Date: Sun, 31 Mar 2002 12:23:59 +0200 [thread overview]
Message-ID: <3CA6E3BF.8815AA4F@isg.de> (raw)
In-Reply-To: Pine.GSO.4.30.0203302133110.7012-100000@shell.cyberus.ca
Hi Jamal,
> in the future can you please just post to netdev on networking
> related issues? I responded to lk, but feel free to remove it
> from the list.
ok. Do all netdev people already know the patch or shall I repost it to
this list?
> -I am not sure the idea of using a kernel thread is the best. Maybe
> move the checks to both the tx or rx softirqs instead of its own scheduling.
> -In particular, it would be a better idea not to just go walking all the
> devices; only walk devices that have raised an netif_carrier_.
Is it possible to send (netlink) messages from a softirq? Anyway, in the
tx/rx softirqs the check would be executed for nearly every packet, so
the tradeoff of having a kernel thread that polls the devices on request
(so may be never as long as the network is fine) seems better to me,
even if it has to walk through the complete list.
> -A shared devices bitmask across SMP should be enough (i.e no need for
> per-CPU state)
Neither dev->flags nor dev->state are per-CPU. Am I missing something?
> -Another thing might be to double check that the condition that raised
> the state change is still valid example -
> in between the moment you say a link is down due to some bad hardware
> fault to the moment some device timer recovers it;
The patch does that. After the thread wakes up, it iterates over the
device list and sends only messages if it sees differences between
IFF_RUNNING and LINK_STATE_NO_CARRIER.
> -Also IFF_RUNNING seems to have inconsistent semantics in a lot of
> drivers. It should really stand for "operational status" whereas
> IFF_UP should stand for "admin status" -- anyone wanna shed historical
> wisdom here?
Ultimately, that's what I want IFF_RUNNING to become in linux.
There are 14 files left below linux/drivers that still play with
IFF_RUNNING instead of using the netif_carrier_o* functions. I'm willing
to supply patches for them as they are broken anyway, but I won't be
able to do more than a test if the modifications compile.
Cheers, Stefan
next parent reply other threads:[~2002-03-31 10:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.4.30.0203302133110.7012-100000@shell.cyberus.ca>
2002-03-31 10:23 ` Stefan Rompf [this message]
2002-03-31 16:21 ` Patch: Device operative state notification against 2.5.7 jamal
2002-04-01 14:44 ` Stefan Rompf
2002-04-01 16:25 ` jamal
2002-04-01 20:31 ` David Brownell
2002-04-02 3:05 ` jamal
2002-03-31 10:23 ` Stefan Rompf
[not found] <3CACB9BC.4D585C25@isg.de>
2002-04-07 20:16 ` jamal
2002-04-07 20:26 ` jamal
2002-04-08 17:48 ` David Brownell
2002-04-07 22:11 ` Michael Richardson
2002-04-08 11:59 ` jamal
2002-04-09 11:28 ` Stefan Rompf
2002-04-11 11:24 ` jamal
2002-04-12 10:12 ` Stefan Rompf
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=3CA6E3BF.8815AA4F@isg.de \
--to=srompf@isg.de \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
/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).