On Wed, 21 Jun 2017 16:04:43 +0300, Gal Pressman wrote: > Hi All, > > Currently, drivers can only tell whether the link is up/down through > ETHTOOL_GLINK callback, but no additional information is given in case > of link down/failure. > > This series provides an infrastructure to ethtool that allows > netdevice drivers to hint the user with the reason why the link is down, > in order to ease the debug process. > > In addition two more mlx5 patches to demonstrate the usage. > > Reasons are separated to two types, generic and vendor specific. > Drivers can reply with a generic reason using the predefined enums > (and the ones that will be added in the future), which will be > translated to strings by the userspace ethtool. > In case of a vendor specific reason, drivers can reply with > ETHTOOL_VENDOR_SPECIFIC reason, in this case the vendor_reason field > should be filled with a vendor specific status code which will be parsed > by the vendor specific userspace parser if one is available. > > This kind of information can save system administrators precious time, > which will not be wasted trying to understand why the link won't go up. > > For example, when the cable is unplugged: > $ ethtool ethXX > ... > Link detected: no (Cable unplugged)
Any particular reason for implementing this ABI in ethtool rather than via some netlink-based interface? Devlink naturally comes to mind, given that cabling problems are not really related to the L2 and netdev shouldn't be required for diagnostics..
