Re: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state
On 07-Jun-20 22:11, Florian Fainelli wrote: > > > On 6/7/2020 7:59 AM, Amit Cohen wrote: >> Add link extended state attributes. >> >> Signed-off-by: Amit Cohen >> Reviewed-by: Petr Machata >> Reviewed-by: Jiri Pirko > > If you need to resubmit, I would swap the order of patches #4 and #5 > such that the documentation comes first. > > [snip] ok > >> >> +Link extended states: >> + >> + >> = >> + ``Autoneg failure`` Failure during auto negotiation mechanism >> + >> + ``Link training failure`` Failure during link training >> + >> + ``Link logical mismatch`` Logical mismatch in physical coding >> sublayer >> + or forward error correction sublayer >> + >> + ``Bad signal integrity``Signal integrity issues >> + >> + ``No cable``No cable connected >> + >> + ``Cable issue`` Failure is related to cable, >> + e.g., unsupported cable >> + >> + ``EEPROM issue``Failure is related to EEPROM, e.g., >> failure >> + during reading or parsing the data >> + >> + ``Calibration failure`` Failure during calibration algorithm >> + >> + ``Power budget exceeded`` The hardware is not able to provide the >> + power required from cable or module >> + >> + ``Overheat``The module is overheated >> + >> = >> + >> +Many of the substates are obvious, or terms that someone working in the >> +particular area will be familiar with. The following table summarizes some >> +that are not: > > Not sure this comment is helping that much, how about documenting each > of the sub-states currently defined, even if this is just paraphrasing > their own name? Being able to quickly go to the documentation rather > than looking at the header is appreciable. > > Thank you! np, I'll add. > >> + >> +Link extended substates: >> + >> + >> = >> + ``Unsupported rate``The system attempted to operate the cable >> at >> + a rate that is not formally supported, >> which >> + led to signal integrity issues > > Do you have examples? Would you consider a 4-pair copper cable for > Gigabit that has a damaged pair and would downshift somehow fall in that > category? > For example, this statement might appear when an 100G OPTICs (not copper) which is used in 40G rate and sees high BER (when using Parallel Detect). In this situation we recommend to see the other end configuration and understand why it is configured to lower speed. Regarding your example, if it stays on the same speed and have high BER you should expect a different BAD SI statement.
Re: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state
On Mon, Jun 08, 2020 at 10:02:04AM +, Amit Cohen wrote: > Andrew Lunn writes: > > >> +Link extended states: > >> + > >> + > >> = > >> + ``Autoneg failure`` Failure during auto negotiation > >> mechanism > > > >I think you need to define 'failure' here. > > > >Linux PHYs don't have this state. auto-neg is either ongoing, or has > >completed. There is no time limit for auto-neg. If there is no link partner, > >auto-neg does not fail, it just continues until there is a link partner > >which responds and negotiation completes. > > > >Looking at the state diagrams in 802.3 clause 28, what do you consider as > >failure? > > > > Ok, you're right. What about renaming this state to "Autoneg issue" and then > as ext_substate you can use something like "Autoneg ongoing"? Hi Amit I'm not sure 'issue' is correct here. Just because it has not completed does not mean there is an issue. It takes around 1.5 seconds anyway, best case. And if there is no link partner, it is not supposed to complete. So i would suggest just ``Autoneg``. Andrew
RE: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state
Andrew Lunn writes: >> +Link extended states: >> + >> + >> = >> + ``Autoneg failure`` Failure during auto negotiation mechanism > >I think you need to define 'failure' here. > >Linux PHYs don't have this state. auto-neg is either ongoing, or has >completed. There is no time limit for auto-neg. If there is no link partner, >auto-neg does not fail, it just continues until there is a link partner which >responds and negotiation completes. > >Looking at the state diagrams in 802.3 clause 28, what do you consider as >failure? > Ok, you're right. What about renaming this state to "Autoneg issue" and then as ext_substate you can use something like "Autoneg ongoing"? >Andrew
Re: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state
On 6/7/2020 7:59 AM, Amit Cohen wrote: > Add link extended state attributes. > > Signed-off-by: Amit Cohen > Reviewed-by: Petr Machata > Reviewed-by: Jiri Pirko If you need to resubmit, I would swap the order of patches #4 and #5 such that the documentation comes first. [snip] > > +Link extended states: > + > + > = > + ``Autoneg failure`` Failure during auto negotiation mechanism > + > + ``Link training failure`` Failure during link training > + > + ``Link logical mismatch`` Logical mismatch in physical coding > sublayer > + or forward error correction sublayer > + > + ``Bad signal integrity``Signal integrity issues > + > + ``No cable``No cable connected > + > + ``Cable issue`` Failure is related to cable, > + e.g., unsupported cable > + > + ``EEPROM issue``Failure is related to EEPROM, e.g., failure > + during reading or parsing the data > + > + ``Calibration failure`` Failure during calibration algorithm > + > + ``Power budget exceeded`` The hardware is not able to provide the > + power required from cable or module > + > + ``Overheat``The module is overheated > + > = > + > +Many of the substates are obvious, or terms that someone working in the > +particular area will be familiar with. The following table summarizes some > +that are not: Not sure this comment is helping that much, how about documenting each of the sub-states currently defined, even if this is just paraphrasing their own name? Being able to quickly go to the documentation rather than looking at the header is appreciable. Thank you! > + > +Link extended substates: > + > + > = > + ``Unsupported rate``The system attempted to operate the cable > at > + a rate that is not formally supported, > which > + led to signal integrity issues Do you have examples? Would you consider a 4-pair copper cable for Gigabit that has a damaged pair and would downshift somehow fall in that category? -- Florian
Re: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state
> +Link extended states: > + > + > = > + ``Autoneg failure`` Failure during auto negotiation mechanism I think you need to define 'failure' here. Linux PHYs don't have this state. auto-neg is either ongoing, or has completed. There is no time limit for auto-neg. If there is no link partner, auto-neg does not fail, it just continues until there is a link partner which responds and negotiation completes. Looking at the state diagrams in 802.3 clause 28, what do you consider as failure? Andrew
