Ethernet Switch Framework

[Stefan Bethke]

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.

> 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