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>