atom feed22 messages in org.freebsd.freebsd-archRe: Ethernet Switch Framework
FromSent OnAttachments
Aleksandr RybalkoJan 20, 2012 12:12 pm 
Stefan BethkeJan 20, 2012 3:34 pm 
Stefan BethkeJan 22, 2012 7:30 am 
Aleksandr RybalkoJan 22, 2012 9:51 am 
Adrian ChaddJan 24, 2012 11:12 pm 
Stefan BethkeJan 25, 2012 12:57 am 
Adrian ChaddJan 26, 2012 10:03 pm 
Aleksandr RybalkoJan 28, 2012 2:12 pm 
Juli MallettJan 28, 2012 2:59 pm 
Warner LoshJan 28, 2012 11:05 pm 
Aleksandr RybalkoJan 29, 2012 3:14 am 
Stefan BethkeJan 29, 2012 4:25 am 
Aleksandr RybalkoJan 29, 2012 4:43 am 
Stefan BethkeJan 29, 2012 4:48 am 
Stefan BethkeJan 29, 2012 5:14 am 
Marius StroblJan 29, 2012 7:31 am 
Stefan BethkeJan 29, 2012 8:00 am 
Marius StroblJan 29, 2012 8:19 am 
Stefan BethkeJan 29, 2012 8:21 am 
Marius StroblJan 29, 2012 9:31 am 
Adrian ChaddJan 29, 2012 10:59 am 
Marius StroblJan 29, 2012 2:12 pm 
Subject:Re: Ethernet Switch Framework
From:Stefan Bethke (st@lassitu.de)
Date:Jan 29, 2012 4:25:37 am
List:org.freebsd.freebsd-arch

Am 29.01.2012 um 00:00 schrieb Juli Mallett:

On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko <ra@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