lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 18 Jun 2010 09:33:09 +0200
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
Cc:	netdev@...r.kernel.org
Subject: Re: Distributed Switch Architecture(DSA)

On Fri, Jun 18, 2010 at 09:06:52AM +0200, Joakim Tjernlund wrote:

> I am trying to wrap my head around DSA and I need some help.
> 
> Assume the example from Lennert:
> 
> 		 +-----------+       +-----------+
> 		 |           | RGMII |           |
> 		 |           +-------+           +------ 1000baseT MDI ("WAN")
> 		 |           |       |  6-port   +------ 1000baseT MDI ("LAN1")
> 		 |    CPU    |       |  ethernet +------ 1000baseT MDI ("LAN2")
> 		 |           |MIImgmt|  switch   +------ 1000baseT MDI ("LAN3")
> 		 |           +-------+  w/5 PHYs +------ 1000baseT MDI ("LAN4")
> 		 |           |       |           |
> 		 +-----------+       +-----------+
> 
> If I understand this correctly I get at least 5 virtual I/Fs corresponding
> to WAN, LAN1-4, but how is the RGMII I/F modelled?

The RGMII interface is just the interface that your "real" network
driver exports.  In the case of the Kirkwood 6281 A0 Reference Design
(which I developed this code on), that would be eth0.  After the DSA
driver is instantiated, you don't send or receive over eth0 directly
anymore -- eth0 becomes purely a transport for DSA-tagged packets.


> I guess I will have one "real" ethX I/F which maps to RGMII but do I
> get one virtual I/F too?

You get a virtual interface for each of the ports on the switch (that
are not CPU or inter-switch ports), i.e. all ports on the right of the
diagram -- wan, lan1, lan2, lan3, lan4.  These interfaces are created
by net/dsa/slave.c and are called DSA interfaces or slave interfaces.


> What use are these virtual I/Fs? Just to read status from the
> corresponding ports?

That's one of the purposes, yes.  There's a polling routine that
periodically checks the status of each of the ports on the switch (via
the MII management interface) and feeds back that status to the virtual
interfaces.  I.e. if you plug a cable into lan3, you'll see a syslog
message about the link on the virtual interface lan3 having come up,
with the link speed, etc.


> Can one TX and RX network pkgs over these I/Fs too?

Sure -- that's the whole point.


> Now I want to add STP/RSTP to the switch. How would one do that?

First, you'll want the hardware bridging patches that I posted to
netdev@ a while back, e.g.:

	http://patchwork.ozlabs.org/patch/16578/

They aren't in upstream-mergeable form in their current form, but they
do the job.  These will propagate brctl addif/delif calls into the switch
chip, so that switching between those ports will be done in hardware.

Now if all you want is regular STP, with that patch you'll be done --
the ->bridge_set_stp_state() hook propagates the spanning tree state of
each of the DSA virtual interfaces into the switch chip automatically.

If you want to use a userspace STP implementation, you'll just have to
make sure that STP state (listening/learning/blocking/forwarding/etc) is
correctly propagated to the switch chip similarly to how it's done in the
patch.

(Ideally, these patches should be reworked to receive bridge configuration
and port status changes via netlink.  Unfortunately, I was asked to return
all my Marvell hardware when I left Marvell, so someone else will have to
do this work.)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ