Ethernet Switch Framework

[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?

It makes me wonder if the understanding of the relationship in FreeBSD
isn't backwards.  Yes, the MAC sits on a bus and is memory-mapped, but
you can conceptualize of it as a child of the PHY, rather than the
parent of it, especially in systems with switch chipsets.  Especially
in systems where there is a switch chipset attached to multiple MACs.

In that model, it makes sense to semi-generically attach a
CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware)
to a MAC generically, but that doesn't meant that the switch itself is
attached generically to the MAC.

There 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.

Thanks,
Juli.