From: Mathieu Olivari <mathieu@codeaurora.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
netdev <netdev@vger.kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
Jonas Gorski <jogo@openwrt.org>
Subject: Re: RFC: dsa: add support for multiple CPU ports
Date: Wed, 11 Mar 2015 16:37:40 -0700 [thread overview]
Message-ID: <20150311233738.GA5566@codeaurora.org> (raw)
In-Reply-To: <20150311133057.GA9601@lunn.ch>
On Wed, Mar 11, 2015 at 02:30:57PM +0100, Andrew Lunn wrote:
> > We already have existing interface for eth0/eth1. Maybe we should
> > consider allowing them to be bridge. User configuration would look like
> > this:
> >
> > brctl addbr br-lan
> > brctl addif br-lan eth1
> > brctl addif br-lan lan1
> > brctl addif br-lan lan2
> > brctl addif br-lan lan3
> > brctl addif br-lan lan4
>
> Think about this from the perspective of somebody how does not know
> there is a switch. When i look at this, to me it means packets from
> lan1, lan2, lan3, lan4 and eth1 are bridged together. So we are going
> to get packets sent out eth1 without a tag on it, and the switch is
> very likely to drop it, since the port is in a mode which expects a
> tag. You are not using the brctl command with its normal meaning,
> which is bad.
>
> Configuring this at the bridge layer is also wrong. What conduit a DSA
> slave interfaces uses is a DSA layer issue.
>
> Before we can come up with a nice solution, i think we first need to
> understand what the switches are capable off. If trunking does work,
> it is a relatively nice system for the user to configure, in that
> there is nothing for the user to configure! Assuming the switch can do
> reasonable load balancing, we also get near optimal usage of the two
> conduits.
>
Agreed. The switches I'm talking about (QCA8xxx/AR8xxx) don't support
a mode which would allow them to use all the CPU ports as one logical
bonding interface. I'm not sure how many of the switches in OpenWrt do.
I know some of these switches don't even support tagging. So I'd be
surprised if they're all capable of bonding.
The base usage scenario for these switches is using port based vlan.
The user knows very well there is a switch (OpenWrt even has a webpage
for it), and he provides a static configuration by telling it how he
want the ports to be connected to each other.
In the previous example, it would be something like creating 2 logical
switches: P0/P1 and P2/P3/P4/P5/P6. Or it could be something like
(lan1 - P0/P1/P2) and (lan2 - P3/P4) and (lan3 - P5/P6). Or anything else.
That's the mode that OpenWrt is using in pretty much all its target. It is
also the way they get configured in most home routers in general.
I understand the value of using bonding. But we should also have a way to
configure more simple hardware - which is typically using port based vlan.
> I don't know when i will have time to play with this, and if somebody
> comes along with a better idea, i'm very open to adopting that idea
> over mine.
I think DSA should probably support both. I think it should allow
bonding for switches who support it, but it should also allow for port
based vlan mapped by the user.
Another way to support these could be to make the cpu port "optional".
These switches would have no cpu port, all the ports would have a
net_device (including the xMII ones). They would get bridged, and
packets that are sent to interface connected to cpu would be dropped by
the switch xmit function.
I didn't try that, but it should work.
>
> Andrew
next prev parent reply other threads:[~2015-03-11 23:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 19:01 RFC: dsa: add support for multiple CPU ports Mathieu Olivari
2015-03-10 19:21 ` Andrew Lunn
2015-03-10 22:13 ` Mathieu Olivari
2015-03-10 22:50 ` Andrew Lunn
2015-03-10 19:31 ` Andrew Lunn
2015-03-10 20:42 ` Mathieu Olivari
2015-03-10 21:13 ` Andrew Lunn
2015-03-10 22:53 ` Mathieu Olivari
2015-03-11 1:47 ` David Miller
2015-03-11 13:07 ` Jiri Pirko
2015-03-11 0:01 ` Florian Fainelli
2015-03-11 1:18 ` Mathieu Olivari
2015-03-11 13:30 ` Andrew Lunn
2015-03-11 23:37 ` Mathieu Olivari [this message]
2015-03-12 0:19 ` Andrew Lunn
2015-03-13 1:57 ` Mathieu Olivari
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=20150311233738.GA5566@codeaurora.org \
--to=mathieu@codeaurora.org \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=jogo@openwrt.org \
--cc=linux@roeck-us.net \
--cc=netdev@vger.kernel.org \
/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).