Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1344712

Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control

From Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Newsgroups linux.kernel
Subject Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control
Date 2016-02-26 22:40 +0100
Message-ID <r6yhe-RJ-51@gated-at.bofh.it> (permalink)
References <r6v9E-7fn-13@gated-at.bofh.it> <r6vjl-7ja-33@gated-at.bofh.it> <r6xuO-j0-19@gated-at.bofh.it> <r6xOa-G1-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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):

Port #   Port Type     VLANTable Setting
0        LAN           0x4E
1        LAN           0x4D
2        LAN           0x4B
3        LAN           0x47
4        WAN           0x20
5        CPU           0x10
6        CPU           0x0F

> The CPU port needs to be able to send to each external port. The whole
> DSA concept is that Linux has a netdev per external port, and can send
> frames using the netdev out a specific port. Such frames have a DSA
> header indicating which port they are destined to.  When you have a
> multi chip setup, the frame needs to traverse DSA ports.

This current patch produces to following setup at setup:

Port  0  1  2  3  4  5  6
  0   -  -  -  -  -  *  *
  1   -  -  -  -  -  *  *
  2   -  -  -  -  -  *  *
  3   -  -  -  -  -  *  *
  4   -  -  -  -  -  *  *
  5   *  *  *  *  *  -  *
  6   *  *  *  *  *  *  -

Here, 5 is the CPU port and 6 is a DSA port.

After joining ports 0, 1, 2 in the same bridge, we end up with:

Port  0  1  2  3  4  5  6
  0   -  *  *  -  -  *  *
  1   *  -  *  -  -  *  *
  2   *  *  -  -  -  *  *
  3   -  -  -  -  -  *  *
  4   -  -  -  -  -  *  *
  5   *  *  *  *  *  -  *
  6   *  *  *  *  *  *  -

Thanks,
-v

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH net-next 0/9] net: dsa: mv88e6xxx: implement VLAN filtering Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
  [PATCH net-next 2/9] net: dsa: mv88e6xxx: extract single VLAN retrieval Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
  [PATCH net-next 4/9] net: dsa: mv88e6xxx: assign dynamic FDB to VLANs Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
  [PATCH net-next 6/9] net: dsa: mv88e6xxx: assign dynamic FDB to bridges Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
  [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
    Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Kevin Smith <kevin.smith@elecsyscorp.com> - 2016-02-26 21:50 +0100
      Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Andrew Lunn <andrew@lunn.ch> - 2016-02-26 22:10 +0100
        Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 22:40 +0100
          Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Andrew Lunn <andrew@lunn.ch> - 2016-02-26 23:10 +0100
          Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Kevin Smith <kevin.smith@elecsyscorp.com> - 2016-02-26 23:30 +0100
            Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Andrew Lunn <andrew@lunn.ch> - 2016-02-26 23:40 +0100
              Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Kevin Smith <kevin.smith@elecsyscorp.com> - 2016-02-26 23:50 +0100
                Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map  control Andrew Lunn <andrew@lunn.ch> - 2016-02-27 04:20 +0100
  [PATCH net-next 3/9] net: dsa: mv88e6xxx: extract single FDB dump Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2016-02-26 19:30 +0100
  Re: [PATCH net-next 0/9] net: dsa: mv88e6xxx: implement VLAN  filtering David Miller <davem@davemloft.net> - 2016-03-01 22:30 +0100

csiph-web