From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 12:44:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 128CF1065672; Sun, 29 Jan 2012 12:44:31 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3B488FC14; Sun, 29 Jan 2012 12:44:28 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1254080eaa.13 for ; Sun, 29 Jan 2012 04:44:28 -0800 (PST) Received: by 10.213.102.12 with SMTP id e12mr2259927ebo.128.1327841067864; Sun, 29 Jan 2012 04:44:27 -0800 (PST) Received: from rnote.ddteam.net (238-239-92-178.pool.ukrtel.net. [178.92.239.238]) by mx.google.com with ESMTPS id t11sm30969724eea.10.2012.01.29.04.44.25 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 04:44:27 -0800 (PST) Date: Sun, 29 Jan 2012 14:44:13 +0200 From: Aleksandr Rybalko To: Stefan Bethke Message-Id: <20120129144413.a8045873.ray@ddteam.net> In-Reply-To: <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Juli Mallett , FreeBSD Net , Adrian Chadd , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 12:44:31 -0000 On Sun, 29 Jan 2012 13:26:00 +0100 Stefan Bethke wrote: > Am 29.01.2012 um 00:00 schrieb Juli Mallett: > > > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko > > 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 Fon +49 151 14070811 > > > -- Aleksandr Rybalko