This is a very interesting observation. I've just worked my way through the MII code to add link state notification to the routing socket and had to remove a couple of return(0) when the link is up to break so the later status function can read the MII and announce the state change if neccessary. Based on your explanation this seems to be a regression and I will look at how to work around this.
Do you have any idea how to make the MII access faster or to get some sort of async notification from the hardware when the link state changes so we don't have to poll every second?
Apart from cautiously removing the DELAY(1) and retesting each driver on a few different hardware platforms there are a couple of other small improvements that could be considered:
1. Not all PHYs need resyncing on every operation - which would obviously eliminate half the access time
2. Only do autoneg operations every 10 seconds (although I think 17 is the current period for MII autoneg timeout?) - at least this will help minimise per second operations.
A handful of PHYs appear to support a form of link state interrupt but given it hasn't already been implemented I'm suspecting broken hardware - not to mention the additional driver complexity necessary for a small gain.
David
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
