Randy Fishel wrote:
> On Mon, 15 Oct 2007, 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.
>>
>> Anyway, I'd like the project team to consider how this could be retrofitted
>> in
>> the future without breaking any interfaces that are being presented today.
>> It
>> is possible that the interfaces (properties) that are being proposed today
>> might need either a lower commitment level, or maybe we can imagine a better
>> set of properties or even a simple enhancement to the properties to
>> accommodate this kind of future enhancement. (Perhaps an additional set of
>> properties?)
>>
>> One possible approach (and I'm not sure that this is the best way, but I'm
>> just offering it as a strawman and I'd really like to hear the project team's
>> thoughts!) might be:
>>
>> * change adv_xxx spec to indicate that this is a read-only property
>> indicating the NIC's MII register contents
>> * 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).
>>
>
> One caution is to make sure that these shouldn't be defined, saved,
> or controlled in the PM framework policy file(s). It is important to
> make sure that policy has one entry point (and the PM entry point
> already exists). I do see that this is proposed as the control point
> (which should be ok), but try and keep away from defining PM policy
> here.
>
Perhaps the "enabling" feature shouldn't be here.
I do think that this should ultimately be driven out of a driver's
power(9e) entry point, but the problem is an overlap in administration
between what is normal for a NIC, and what is normal for power management.
I agree that for the most part, policy needs to come from the PM
framework. The question is that this will impact other visible parts of
the administration, and we need to figure out a way for an administrator
to figure out just what is going on.
- Garrett
> ---- Randy
>
>
>> 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.)
>>
>> And to be clear, I don't think we are going to go very long at all before NIC
>> drivers start looking for this kind of feature... projects like Tesla, laptop
>> suspend/resume, and wake-on-lan demonstrate that power savings features are
>> becoming very important.
>>
>> -- Garrett
>>
>>
>>
>
>
