Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages

From: Andrew Lunn <[email-masked]>
Date: Mon, 18 Mar 2019 14:33:23 +0100

On Mon, Mar 18, 2019 at 01:15:41PM +0000, Petr Machata wrote:
> 
> Andrew Lunn <[email-masked]> writes:
> 
> >> +enum rtnl_link_down_reason_major {
> >> +	RTNL_LDR_OTHER,
> >
> > Does 'other' make any sense? Seem better to just not report anything
> > at all, or add a comment that more reasons should be added at the end
> > to reflect whatever the hardware or software can determine.
> 
> You still have the minor code to give you some information.
> 
> >> +	RTNL_LDR_NO_CABLE,
> >> +	RTNL_LDR_UNSUPPORTED_CABLE,
> >> +	RTNL_LDR_AUTONEG_FAILURE,
> >> +	RTNL_LDR_NO_LINK_PARTNER,
> >> +	RTNL_LDR_LINK_TRAINING_FAILURE,
> >> +	RTNL_LDR_LOGICAL_MISMATCH,
> >> +	RTNL_LDR_REMOTE_FAULT,
> >> +	RTNL_LDR_BAD_SIGNAL_INTEGRITY,
> >> +	RTNL_LDR_CALIBRATION_FAILURE,
> >> +	RTNL_LDR_POWER_BUDGET_EXCEEDED,
> >> +};
> >
> > What about SFP cage empty?, i.e. no SFP, SFP+ module in the cage?  An
> 
> No cable? Maybe the name needs to change...

An SFP module, and the cable plugged into it via LC connectors, are
physically different things. And you can also have an SFP with an RJ45
for 1G copper. I know at higher speeds they can be inseparable, but
this needs to be a generic API and also work with them being two
separate things. 

> 
> > SFP can also report LOS. That does not appear to be any of the above.
> > Or that the core SFP code has been unable to read the EEPROM? We have
> 
> My assumption was that cable with unreadable EEPROM is simply a bad
> cable. Does the admin actually care which particular part of the cable
> is at fault?

Yes. I throw away the SFP module, because its EEPROM is broke, but
don't need to replace the 1KM of fibre cable, or 100m of Cat 6a copper
cable. Classic example would be fibre to the home. Do you really think
they are going to dig up the road again, to replace the cable, when
all they need to do is replace the SFP module?

	Andrew