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).
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
