From: Andrew Lunn <andrew@lunn.ch>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Kevin Smith <kevin.smith@elecsyscorp.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel@savoirfairelinux.com" <kernel@savoirfairelinux.com>,
"David S. Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
Guenter Roeck <linux@roeck-us.net>,
Neil Armstrong <narmstrong@baylibre.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Russell King <rmk+kernel@arm.linux.org.uk>
Subject: Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control
Date: Fri, 26 Feb 2016 23:09:42 +0100 [thread overview]
Message-ID: <20160226220942.GB1560@lunn.ch> (raw)
In-Reply-To: <87d1rj6tlo.fsf@ketchup.mtl.sfl>
On Fri, Feb 26, 2016 at 04:37:39PM -0500, Vivien Didelot wrote:
> Hi Kevin, Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > On Fri, Feb 26, 2016 at 08:45:28PM +0000, Kevin Smith wrote:
> >> Hi Vivien,
> >>
> >> On 02/26/2016 12:16 PM, Vivien Didelot wrote:
> >> > + /* allow CPU port or DSA link(s) to send frames to every port */
> >> > + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)) {
> >> > + output_ports = mask;
> >> > + } else {
> >
> >> Is this always correct? Are there situations where a CPU or neighboring
> >> switch should not be allowed to access another port? (e.g. Figure 6 or 7
> >> in the 88E6352 functional specification).
>
> Given Linux expectations (described below by Andrew) I'd say yes, this
> is always correct. But I'd be curious to know if someone has counter
> examples for this.
>
> > What do these figures show?
>
> The figure shows the following VLANTable config:
>
> Port 0 1 2 3 4 5 6
> 0 - * * * - - *
> 1 * - * * - - *
> 2 * * - * - - *
> 3 * * * - - - *
> 4 - - - - - * -
> 5 - - - - * - -
> 6 * * * * - - -
>
> There is two independant groups: 0, 1, 2, 3, 6 (LAN, 6 is CPU/Router),
> and 4, 5 (4 is WAN and 5 is CPU/Router):
Ah, two CPU interfaces. We don't support that yet. I do have patches,
but i took a different approach. They just load balance, by some
definition of 'load balance' between the two CPU ports.
Andrew
next prev parent reply other threads:[~2016-02-26 22:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 18:15 [PATCH net-next 0/9] net: dsa: mv88e6xxx: implement VLAN filtering Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 1/9] net: dsa: support VLAN filtering switchdev attr Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 2/9] net: dsa: mv88e6xxx: extract single VLAN retrieval Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 3/9] net: dsa: mv88e6xxx: extract single FDB dump Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 4/9] net: dsa: mv88e6xxx: assign dynamic FDB to VLANs Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 5/9] net: dsa: mv88e6xxx: assign default FDB to ports Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 6/9] net: dsa: mv88e6xxx: assign dynamic FDB to bridges Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control Vivien Didelot
2016-02-26 20:45 ` Kevin Smith
2016-02-26 21:04 ` Andrew Lunn
2016-02-26 21:37 ` Vivien Didelot
2016-02-26 22:09 ` Andrew Lunn [this message]
2016-02-26 22:12 ` Kevin Smith
2016-02-26 22:35 ` Andrew Lunn
2016-02-26 22:47 ` Kevin Smith
2016-02-27 3:14 ` Andrew Lunn
2016-02-26 18:16 ` [PATCH net-next 8/9] net: dsa: mv88e6xxx: remove reserved VLANs Vivien Didelot
2016-02-26 18:16 ` [PATCH net-next 9/9] net: dsa: mv88e6xxx: support VLAN filtering Vivien Didelot
2016-03-01 21:25 ` [PATCH net-next 0/9] net: dsa: mv88e6xxx: implement " David Miller
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=20160226220942.GB1560@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kernel@savoirfairelinux.com \
--cc=kevin.smith@elecsyscorp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=narmstrong@baylibre.com \
--cc=netdev@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=s.hauer@pengutronix.de \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=vivien.didelot@savoirfairelinux.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).