* bridge interface initial carrier state
@ 2013-02-11 20:01 Dan Williams
2013-02-11 21:58 ` Stephen Hemminger
2013-02-11 21:59 ` Stephen Hemminger
0 siblings, 2 replies; 6+ messages in thread
From: Dan Williams @ 2013-02-11 20:01 UTC (permalink / raw)
To: netdev
Hi,
I'm wondering if the initial carrier state of 'on' is intentional for a
bridge without ports; immediately after adding ports, the carrier is
recalculated and depends on the combined state of each port's carrier
and STP forwarding state. So a userspace program attempting to decide
whether the bridge was usable or not has to look at both (a) how many
ports are available and (b) bridge carrier state, instead of just
looking at the bridge carrier state.
Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bridge interface initial carrier state
2013-02-11 20:01 bridge interface initial carrier state Dan Williams
@ 2013-02-11 21:58 ` Stephen Hemminger
2013-02-12 21:06 ` Jiri Pirko
2013-02-11 21:59 ` Stephen Hemminger
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2013-02-11 21:58 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
On Mon, 11 Feb 2013 14:01:55 -0600
Dan Williams <dcbw@redhat.com> wrote:
> Hi,
>
> I'm wondering if the initial carrier state of 'on' is intentional for a
> bridge without ports; immediately after adding ports, the carrier is
> recalculated and depends on the combined state of each port's carrier
> and STP forwarding state. So a userspace program attempting to decide
> whether the bridge was usable or not has to look at both (a) how many
> ports are available and (b) bridge carrier state, instead of just
> looking at the bridge carrier state.
>
> Dan
It really should be off when no ports are present, but some initial startup
scripts broke when it was that way.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bridge interface initial carrier state
2013-02-11 20:01 bridge interface initial carrier state Dan Williams
2013-02-11 21:58 ` Stephen Hemminger
@ 2013-02-11 21:59 ` Stephen Hemminger
2013-02-11 22:46 ` Dan Williams
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2013-02-11 21:59 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
On Mon, 11 Feb 2013 14:01:55 -0600
Dan Williams <dcbw@redhat.com> wrote:
> Hi,
>
> I'm wondering if the initial carrier state of 'on' is intentional for a
> bridge without ports; immediately after adding ports, the carrier is
> recalculated and depends on the combined state of each port's carrier
> and STP forwarding state. So a userspace program attempting to decide
> whether the bridge was usable or not has to look at both (a) how many
> ports are available and (b) bridge carrier state, instead of just
> looking at the bridge carrier state.
>
> Dan
Perhaps a future enhancement of bridge would be to use operstate flags
to indicate lower layer down if there are no ports.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bridge interface initial carrier state
2013-02-11 21:59 ` Stephen Hemminger
@ 2013-02-11 22:46 ` Dan Williams
0 siblings, 0 replies; 6+ messages in thread
From: Dan Williams @ 2013-02-11 22:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
On Mon, 2013-02-11 at 13:59 -0800, Stephen Hemminger wrote:
> On Mon, 11 Feb 2013 14:01:55 -0600
> Dan Williams <dcbw@redhat.com> wrote:
>
> > Hi,
> >
> > I'm wondering if the initial carrier state of 'on' is intentional for a
> > bridge without ports; immediately after adding ports, the carrier is
> > recalculated and depends on the combined state of each port's carrier
> > and STP forwarding state. So a userspace program attempting to decide
> > whether the bridge was usable or not has to look at both (a) how many
> > ports are available and (b) bridge carrier state, instead of just
> > looking at the bridge carrier state.
> >
> > Dan
>
> Perhaps a future enhancement of bridge would be to use operstate flags
> to indicate lower layer down if there are no ports.
While we're at it, it appears that if a bridge port is added when it has
no carrier, nothing directly triggers br_port_state_selection() to
ensure that the bridge's carrier state is correct:
if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
(br->dev->flags & IFF_UP))
br_stp_enable_port(p);
Any reason why we can't run br_port_state_selection() unconditionally
when adding a new port? When removing a port that gets run by
br_stp_disable_port(), which is somewhat asymmetrical.
When adding, we don't necessarily want to enable STP operation on the
port until it's ready, so that hunk above for br_stp_enable_port() is
probably just fine, but we should still probably be recalculating the
bridge's carrier when it gets its first port even if that port isn't yet
usable? Or not?
Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bridge interface initial carrier state
2013-02-11 21:58 ` Stephen Hemminger
@ 2013-02-12 21:06 ` Jiri Pirko
2013-02-12 21:10 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Jiri Pirko @ 2013-02-12 21:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dan Williams, netdev
Mon, Feb 11, 2013 at 10:58:36PM CET, stephen@networkplumber.org wrote:
>On Mon, 11 Feb 2013 14:01:55 -0600
>Dan Williams <dcbw@redhat.com> wrote:
>
>> Hi,
>>
>> I'm wondering if the initial carrier state of 'on' is intentional for a
>> bridge without ports; immediately after adding ports, the carrier is
>> recalculated and depends on the combined state of each port's carrier
>> and STP forwarding state. So a userspace program attempting to decide
>> whether the bridge was usable or not has to look at both (a) how many
>> ports are available and (b) bridge carrier state, instead of just
>> looking at the bridge carrier state.
>>
>> Dan
>
>It really should be off when no ports are present, but some initial startup
>scripts broke when it was that way.
How so? Can you give me an example of that script?
I think that any script should be able to handle a situation when carrier
of some device is down...
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bridge interface initial carrier state
2013-02-12 21:06 ` Jiri Pirko
@ 2013-02-12 21:10 ` David Miller
0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2013-02-12 21:10 UTC (permalink / raw)
To: jiri; +Cc: stephen, dcbw, netdev
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 22:06:05 +0100
> Mon, Feb 11, 2013 at 10:58:36PM CET, stephen@networkplumber.org wrote:
>>On Mon, 11 Feb 2013 14:01:55 -0600
>>Dan Williams <dcbw@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I'm wondering if the initial carrier state of 'on' is intentional for a
>>> bridge without ports; immediately after adding ports, the carrier is
>>> recalculated and depends on the combined state of each port's carrier
>>> and STP forwarding state. So a userspace program attempting to decide
>>> whether the bridge was usable or not has to look at both (a) how many
>>> ports are available and (b) bridge carrier state, instead of just
>>> looking at the bridge carrier state.
>>>
>>> Dan
>>
>>It really should be off when no ports are present, but some initial startup
>>scripts broke when it was that way.
>
> How so? Can you give me an example of that script?
> I think that any script should be able to handle a situation when carrier
> of some device is down...
These are scripts that are looking for interfaces that are "active".
The definition of this for layered and software devices is very
ambiguous, therefore the only sane thing to do is to default to
having the carrier on by default.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-12 21:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-11 20:01 bridge interface initial carrier state Dan Williams
2013-02-11 21:58 ` Stephen Hemminger
2013-02-12 21:06 ` Jiri Pirko
2013-02-12 21:10 ` David Miller
2013-02-11 21:59 ` Stephen Hemminger
2013-02-11 22:46 ` Dan Williams
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).