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. >> 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. >
I'm glad you think so! Any chance of getting this into the commitment materials before Wednesday? (I apologize for not getting you this feedback earlier, but I really only considered the impact on Brussels last night.) > 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 > Ah, this is with the ndd API. As a possible (and hideous!) hack, one could imagine doing the following: * start off with the ndd management interface marked Obsolete. * don't enable link pm features via ndd. * the enable_xxx bits might not be really writeable? * if adv_xxx is written via NDD, treat it as a write to the enable_xxx properties. * if adv_xxx is read via NDD, return the value from the ANAR This means that the adv_xxx values would retain their behavior and meaning via the NDD hack, but that would behave slightly differently if using the newer Brussels API. I will confess, the more and more I think about it, the more and more I start to believe that the ndd interfaces really should just be removed outright. Right now the problem is that a few internal consumers of ndd exist. I don't have a problem with breaking most of them (NICDRV is one such, SunVTS is another), but I'd prefer not to break SunVTS. Maybe this means that SunVTS needs to change. What does the project team, and what does ARC think, about just yanking these interfaces in Nevada, and marking them Obsolete in S10u5? Are we willing to deal with the fallout from the breakage from the places that have done their own thing? IMO, this breakage is not very different from the precedent set by SMF... when SMF came out, a bunch of administrative practice surrounding init.d scripts and inetd.conf was "busted". I think folks adapted rather gracefully to it. Furthermore, I think the scope of breakage that would be created by removing the NDD command and underlying ioctls (at least for NIC drivers) is not too bad. Indeed, not every NIC driver even supports these ioctls. -- Garrett > >> 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 > > >
