Re: Behaviour of ETHTOOL_GLINK for an interface that's down

[Dan Williams <dcbw@redhat.com>]

On Thu, 2010-12-09 at 18:05 +0000, Ben Hutchings wrote:
> On Thu, 2010-12-09 at 00:02 -0600, Dan Williams wrote:
> > On Wed, 2010-12-08 at 23:47 -0600, Dan Williams wrote:
> > > On Mon, 2010-12-06 at 21:59 +0000, Ben Hutchings wrote:
> > > > ETHTOOL_GLINK is yet another ethtool operation that has unclear
> > > > semantics that results in differing behaviour when the interface is
> > > > down.
> [...]
> > > > DaveM said that Network Manager may require (2), although I don't think
> > > > this is correct.  At least the current version brings all managed
> > > > interfaces up whether or not they have link-up already.
> > > 
> > > NM has used netlink + IFF_RUNNING (not ethtool) for a few years for
> > > actual carrier detection.  Ethtool (and MII ioctls) are called as a
> > > "best effort" method of determining that the device actually *has*
> > > carrier detection at all, since if the device has gone to the trouble to
> > > implement either MII or ethtool, it probably also has carrier detection.
> > > 
> > > But ethtool isn't actually used to determine carrier status in NM.  It's
> > > netlink all the way down.
> > 
> > And as a follow-on, yes, NM does bring all devices it is allowed to
> > manager IFF_UP because that's the only way (at this point) that we can
> > guarantee functional carrier detect from the card.  I'd love it if that
> > weren't the case, and if we could have some indicator that the driver
> > could do carrier detect while in a lower-power state and !IFF_UP, but we
> > don't have that yet.
> 
> Thanks for the information, Dan.  Presumably it would actually be
> sufficient for NM's requirements to implement 'energy detect' which some
> PHYs can do even in a low power state?  (Though I wonder whether that
> works between two PHYs both in a low power state.)  You could then use
> this as a trigger to bring the interface up, while still relying on the
> existing link change notification to trigger interface configuration.
> But this clearly has to be separate from ETHTOOL_GLINK, not least
> because you want notification rather than having to poll.

+1 to all of that.  If that showed up, I'd love to use it for NM.

Dan