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.

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


Reply via email to