From: Dan Williams <dcbw@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Vlad Yasevich <vyasevic@redhat.com>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next 2/4] bridge: Allow an ability to designate an uplink port
Date: Thu, 14 Mar 2013 09:53:43 -0500 [thread overview]
Message-ID: <1363272823.1643.4.camel@dcbw.foobar.com> (raw)
In-Reply-To: <20130313203333.GC9821@redhat.com>
On Wed, 2013-03-13 at 22:33 +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 12, 2013 at 09:45:24PM -0400, Vlad Yasevich wrote:
> > Allow a ports to be designated as uplink. Multiple ports
> > may be designated as uplinks and they will be kept in a
> > list.
> >
> > Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>
> It looks like if you make two links uplink, bridging
> between them won't work at all?
Only caught the end of this thread... is there any way to use the
UPLINK flag as part of the bridge master carrier calculation? Obviously
that's technically possible, I'm asking if that's going to break all
sorts of userspace tools and such.
Traditionally for "wired-type" devices like bridge, bond, vlan, wired,
etc, the carrier/LOWER_UP is the way that higher levels know that IP
configuration is possible on the device.
In the case of a bridge, it's not worth trying DHCP or IPv6 RA on the
bridge master until we know that there's an uplink port, otherwise it's
just going to fail. But right now, we have no way of knowing which port
is an uplink port, which this series would clearly solve.
However, bridge master devices calculate their carrier based on the
state of all their ports, but right now all ports are equal. If we used
UPLINK as part of that calculation, then higher level tools would be
notified that the master is LOWER_UP only when it actually was.
If we're worried about backwards compatibility, then perhaps the new
behavior could be enabled only if one or more ports was an UPLINK? Then
userspace tools that cared would monitor bridge ports, and if they cared
about UPLINK could ignore bridge carrier until at least one UPLINK port
was added.
Dan
> > ---
> > include/uapi/linux/if_link.h | 1 +
> > net/bridge/br_netlink.c | 2 ++
> > net/bridge/br_private.h | 1 +
> > net/bridge/br_sysfs_if.c | 2 ++
> > 4 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> > index c4edfe1..b9444e9 100644
> > --- a/include/uapi/linux/if_link.h
> > +++ b/include/uapi/linux/if_link.h
> > @@ -220,6 +220,7 @@ enum {
> > IFLA_BRPORT_GUARD, /* bpdu guard */
> > IFLA_BRPORT_PROTECT, /* root port protection */
> > IFLA_BRPORT_FAST_LEAVE, /* multicast fast leave */
> > + IFLA_BRPORT_UPLINK, /* uplink port */
> > __IFLA_BRPORT_MAX
> > };
> > #define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
> > diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> > index 27aa3ee..e08a50e 100644
> > --- a/net/bridge/br_netlink.c
> > +++ b/net/bridge/br_netlink.c
> > @@ -283,6 +283,7 @@ static const struct nla_policy ifla_brport_policy[IFLA_BRPORT_MAX + 1] = {
> > [IFLA_BRPORT_MODE] = { .type = NLA_U8 },
> > [IFLA_BRPORT_GUARD] = { .type = NLA_U8 },
> > [IFLA_BRPORT_PROTECT] = { .type = NLA_U8 },
> > + [IFLA_BRPORT_UPLINK] = { .type = NLA_U8 },
> > };
> >
> > /* Change the state of the port and notify spanning tree */
> > @@ -329,6 +330,7 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
> > br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
> > br_set_port_flag(p, tb, IFLA_BRPORT_GUARD, BR_BPDU_GUARD);
> > br_set_port_flag(p, tb, IFLA_BRPORT_FAST_LEAVE, BR_MULTICAST_FAST_LEAVE);
> > + br_set_port_flag(p, tb, IFLA_BRPORT_UPLINK, BR_UPLINK);
> >
> > if (tb[IFLA_BRPORT_COST]) {
> > err = br_stp_set_path_cost(p, nla_get_u32(tb[IFLA_BRPORT_COST]));
> > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> > index 4a0fa29..44ae584 100644
> > --- a/net/bridge/br_private.h
> > +++ b/net/bridge/br_private.h
> > @@ -156,6 +156,7 @@ struct net_bridge_port
> > #define BR_BPDU_GUARD 0x00000002
> > #define BR_ROOT_BLOCK 0x00000004
> > #define BR_MULTICAST_FAST_LEAVE 0x00000008
> > +#define BR_UPLINK 0x00000010
> >
> > #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
> > u32 multicast_startup_queries_sent;
> > diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
> > index a1ef1b6..1f28cd4 100644
> > --- a/net/bridge/br_sysfs_if.c
> > +++ b/net/bridge/br_sysfs_if.c
> > @@ -158,6 +158,7 @@ static BRPORT_ATTR(flush, S_IWUSR, NULL, store_flush);
> > BRPORT_ATTR_FLAG(hairpin_mode, BR_HAIRPIN_MODE);
> > BRPORT_ATTR_FLAG(bpdu_guard, BR_BPDU_GUARD);
> > BRPORT_ATTR_FLAG(root_block, BR_ROOT_BLOCK);
> > +BRPORT_ATTR_FLAG(uplink, BR_UPLINK);
> >
> > #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
> > static ssize_t show_multicast_router(struct net_bridge_port *p, char *buf)
> > @@ -195,6 +196,7 @@ static const struct brport_attribute *brport_attrs[] = {
> > &brport_attr_hairpin_mode,
> > &brport_attr_bpdu_guard,
> > &brport_attr_root_block,
> > + &brport_attr_uplink,
> > #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
> > &brport_attr_multicast_router,
> > &brport_attr_multicast_fast_leave,
> > --
> > 1.7.7.6
> >
> > --
> > 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
> --
> 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
next prev parent reply other threads:[~2013-03-14 14:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 1:45 [PATCH net-next 0/4] Allow bridge to function in non-promisc mode Vlad Yasevich
2013-03-13 1:45 ` [PATCH net-next 1/4] bridge: Add sysfs interface to control promisc mode Vlad Yasevich
2013-03-13 15:38 ` Stephen Hemminger
2013-03-13 15:44 ` Vlad Yasevich
2013-03-13 1:45 ` [PATCH net-next 2/4] bridge: Allow an ability to designate an uplink port Vlad Yasevich
2013-03-13 20:33 ` Michael S. Tsirkin
2013-03-13 22:54 ` Stephen Hemminger
2013-03-13 23:43 ` Vlad Yasevich
2013-03-14 14:53 ` Dan Williams [this message]
2013-03-13 1:45 ` [PATCH net-next 3/4] bridge: Implement IFF_UNICAST_FLT Vlad Yasevich
2013-03-13 1:45 ` [PATCH net-next 4/4] bridge: sync device list when a new uplink is designated Vlad Yasevich
2013-03-13 6:22 ` [PATCH net-next 0/4] Allow bridge to function in non-promisc mode "Oleg A. Arkhangelsky"
2013-03-13 12:12 ` Vlad Yasevich
2013-03-13 15:39 ` Stephen Hemminger
2013-03-13 15:45 ` Vlad Yasevich
2013-03-13 16:09 ` Stephen Hemminger
2013-03-13 17:04 ` Vlad Yasevich
2013-03-13 18:56 ` [Bridge] " Joel Wirāmu Pauling
2013-03-13 20:08 ` Michael S. Tsirkin
2013-03-13 20:31 ` Michael S. Tsirkin
2013-03-14 15:10 ` Vlad Yasevich
2013-03-14 17:46 ` Michael S. Tsirkin
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=1363272823.1643.4.camel@dcbw.foobar.com \
--to=dcbw@redhat.com \
--cc=bridge@lists.linux-foundation.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=vyasevic@redhat.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).