Sowmini.Varadhan at Sun.COM wrote: > On (10/15/07 08:20), Garrett D'Amore wrote: > >> I was chatting with some folks at the OpenSolaris Developer Summit, and I >> think the Brussels project needs to consider a possible future enhancement >> that NIC drivers are likely to make. >> >> Specifically, in order to save power, many NIC drivers are likely to want >> to switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. >> This is because running at 1G consumes on average about 1W per port. >> Versus less than 1/10th of that at 100Mbps. >> Under the new EnergyStar spec for workstations, NICs are required to reduce speed below 1G when the system enters sleep or standby mode. Reducing speed under low load is also a requirement under the new EPA EnergyStar proposed "Tier 2" rules for workstations, and probably will also show up in the EnergyStar rules for servers when they are hashed out in the next year or so.
-sarito >> As far as Brussels is concerned, I'm interested in the link state and speed >> properties. Right now the adv_xxx properties indicate both the >> administrator's desired negotiation parameters, and the actual state of the >> MII ANAR register on the PHY. >> >> We need to break that up in the future. Specifically, we are going to need >> a way for the administrator to say "I want autonegotiation, and I'm willing >> to negotiate for everything, but I also want the NIC to downscale the speed >> when the NIC drops below a certain utilization for a while." And we need a >> way to be able to see that. >> >> But *independently*, we need a way to look at the current state of the ANAR >> register for debug. When the NIC is running at a lower speed, it may have >> ANAR register bits cleared that would otherwise be set once the demand for >> bandwidth increases. >> > > Garrett, > > Interesting point. It seems to me that the best way to provision > for advanced power-management concepts would be to add additional > enhanced properties. > > Thus, we could have the existing adv* properties, plus additional > enable_link_pm modifiers (with the associated versions to examine > the link state, and set the capability), i.e., the suggestion below: > > >> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >> which becomes the administrative *control* point. >> * and new properties, "cap_link_pm", "enable_link_pm", and >> "link_pm_state", which are boolean values indicate the ability to do this >> kind of link power management, whether it is turned on, and the current >> state (link speed is reduced for power management or not). >> > > is the ideal solution. > > The existing adv* tunables have been around for far too long, so > lowering their stability with Brussels would discourage adoption, > as Jim points out in > http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000462.html > > >> Note that the above suggestion would require adding new enable_xxx >> properties even to NICs that don't have link power management. (And yes, >> it isn't strictly "required", but it would be a lot simpler if all NICs >> were administered the same way from the first time the project integrated.) >> > > Agreed. As you point out, the set of "public" properties is a rapidly > changing one. The idea, with PSARC 2007/429, is to offer the bare minimum > of interfaces with the framework so that cutting-edge projects like > suspend/resume can contribute/modify the set efficiently. > > --Sowmini > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org >
