Date: Mon, 12 Dec 2011 02:35:35 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Aleksandr Rybalko <ray@ddteam.net> Cc: freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch Message-ID: <CAJ-VmonidWGsLXogrg-hP7i11d-CV7m6V4%2Bw-bEwh=Q2TiH2zQ@mail.gmail.com> In-Reply-To: <20111212011517.ff4b390f.ray@ddteam.net> References: <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> <CAJ-VmomWsGy9wMb0zA-WjTRP6Qh%2BO2u_Pe-rgkerFFpi04iKnw@mail.gmail.com> <6387ABA5-AC55-49DD-9058-E45CC0A3E0A0@lassitu.de> <CAJ-VmonM91s-kbbEqVDy9PvtH-gxLWYmusGiqzqCWMtfMdoo2A@mail.gmail.com> <EA0807C1-6FEE-4743-8DCA-1AC873664005@lassitu.de> <74E4AF57-3D22-415E-B913-176753B09B16@lassitu.de> <710E2C7A-E9AC-4103-8C61-0EDC4A3AF9DE@lassitu.de> <CAJ-Vmo=zn7K35Tk%2BkoHs8Kba9C9ypMCdJjSU=2O1TfwohV9GzQ@mail.gmail.com> <E2992227-7989-4278-8BA8-1ADDA0A58FDC@lassitu.de> <20111212011517.ff4b390f.ray@ddteam.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ray, How does your userland switch configuration tool work? The one that doesn't use the switch API you've designed? I'm wondering if we shouldn't just make the first stage of this be: * Add the glue needed to detect and setup the switch/phy, expose the PHY state and PHY register operations; * fix if_arge to allow this to happen in a not so dirty fashion (ie, remove the arge0/arge1 hard coded distinction, pushing it all into hints); * do the minimum needed to support the setup where arge1 has the switch PHY, and all the odd probing issues that entails; * do the switch configuration via userland for now, rather than the switch API. Since these switch PHYs have a very large set of possible operating modes (including all kinds of L2/L3/L4 ACL modes that we haven't even begun to address, let alone devices which implement hardware NAT) I think the best thing to do right now is the minimum set of stuff needed, then do the rest via userland. As long as the PHY port state is exposed and there is some way to program the arge{0,1} MII mode, clock speed, port speed and port duplex, I think we'll be fine. I'd still like to eventually implement a switch API but I'm concerned about the amount of time it'll take to get it "right", along with all the subsequent features which vary quite wildly with devices. We may end up having to code up a way of implementing (opaque) extensions (so the switch PHY layer doesn't need to know about NAT, for example, but natd can program in rules as needed; same deal for hardware ACLs and QoS), and this may get messy. What do you think? Juli/Warner, what do you two think? Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonidWGsLXogrg-hP7i11d-CV7m6V4%2Bw-bEwh=Q2TiH2zQ>