Ethernet Switch Framework

[Aleksandr Rybalko]

On Sun, 29 Jan 2012 13:26:00 +0100
Stefan Bethke <stb at lassitu.de> wrote:

> Am 29.01.2012 um 00:00 schrieb Juli Mallett:
> 
> > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko <ray at ddteam.net>
> > wrote:
> >> As I see from your patch, mdio/miiproxy require special bits in MAC
> >> driver. When I design switch framework, I keeping in mind that
> >> MAC drivers should be standard as possible
> > 
> > I don't understand why this is desirable in practice.  It's a nice
> > theory, but it falls down when one thinks in depth about how
> > Ethernet interfaces are used and administered vs. how switches are
> > used and administered.  What should media report?  What should
> > media changes do?  What is link status?  Do you show the
> > CPU-to-switch port, or all switch ports?
> 
> The main thrust here is to reuse the existing PHY code to be able to
> configure the PHYs that are embedded in the switch chips. To confuse
> things, one of these PHYs might be connected to the SoCs ethernet
> interface via MII, GMII, etc.  To confuse things further, these PHYs
> are controlled by an MDIO bus that has it's master in the switch
> chip, while the switch chip is a slave to the MDIO master in the
> ethernet controller.
> 
> The goal is to be able to configure the switch ports and set media on
> one of them, for example.  That code path could be entirely
> independent from the ethernet infrastructure, if dev/miibus didn't
> require if_media and hence a struct ifnet.  This discussion is also
> about how to deal with this entanglement.
> 
> The MII connection between the ethernet controller and the switch
> chip (usually referred to as the "CPU" port) is hard-coded and has no
> media settings, so there's no question what if_media settings should
> be presented on the interface.

Most switches (AR8x16 for example) have configurable MII port, so you
can choose to use MII/RMII/GMII/RGMII. If you decide to use MII
media can not be higher than 100baseTX. So it is possible to use some
auto-negotiation here.

> 
> > are a lot of switches out there that don't look or act much like
> > MII-driven PHYs, but which are connected over MDIO, as I've tried to
> > stress before.  I hope there will be as much separation between the
> > MII work that is being done and the switch work that is being done
> > as possible.  I think anything else will prove rapidly-obsolete and
> > perhaps even obstructive as soon as anyone seeks to add support for
> > more switch chipsets to FreeBSD.
> > 
> > I suppose the most likely reality, though, is that people simply
> > won't add switch support to FreeBSD, and will administer them
> > out-of-band from userland, using gross kernel shims.  That is
> > probably true whether any of the currently-outstanding work is
> > committed or not, unfortunately :(  I just hope we'll end up with
> > something flexible enough, broad enough in applicability, narrow
> > enough in requirements, etc., that we'll have feature-rich support
> > for a few chipsets in tree that work in sufficiently-different
> > manners that they can be models for other drivers in the future.
> 
> Which is a valid approach from a vendor's viewpoint.  The reason
> we're talking is to try and make it easier to write a switch driver
> for this framework than roll your own hack. :-)
> 
> 
> Stefan
> 
> -- 
> Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811
> 
> 
> 


-- 
Aleksandr Rybalko <ray at ddteam.net>