From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>, David Miller <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Chris Healy <cphealy@gmail.com>
Subject: Re: [PATCH net-next v1 4/9] net: ethtool: Add attributes for cable test reports
Date: Mon, 27 Apr 2020 09:13:24 +0200 [thread overview]
Message-ID: <20200427071324.GA9038@lion.mk-sys.cz> (raw)
In-Reply-To: <20200426211242.GC1183480@lunn.ch>
On Sun, Apr 26, 2020 at 11:12:42PM +0200, Andrew Lunn wrote:
> > > +
> > > + +-------------------------------------------+--------+-----------------------+
> > > + | ``ETHTOOL_A_CABLE_TEST_HEADER`` | nested | reply header |
> > > + +-------------------------------------------+--------+-----------------------+
> > > + | ``ETHTOOL_A_CABLE_TEST_NTF_RESULT`` | nested | cable test result |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_RESULTS_PAIR`` | u8 | pair number |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_RESULTS_CODE`` | u8 | result code |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | ``ETHTOOL_A_CABLE_TEST_NTF_RESULT`` | nested | cable test results |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_RESULTS_PAIR`` | u8 | pair number |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_RESULTS_CODE`` | u8 | result code |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | ``ETHTOOL_A_CABLE_TEST_NTF_FAULT_LENGTH`` | nested | cable length |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_FAULT_LENGTH_PAIR`` | u8 | pair number |
> > > + +-+-----------------------------------------+--------+-----------------------+
> > > + | | ``ETHTOOL_A_CABLE_FAULT_LENGTH_CM`` | u8 | length in cm |
> > > + +-+-----------------------------------------+--------+-----------------------+
> >
> > Would it be complicated to gather all information for each pair
> > together? I.e. to have one nest for each pair with pair number, result
> > code and possibly other information (if available). I believe it would
> > make the message easier to process.
>
> It is something i considered, but decided against. Attributes give us
> flexibility to report whatever the PHY gives us. There is no
> standardisation here. Some PHYs will report the first fault on a
> pair. Others will report multiple faults on a pair. Some PHYs can tell
> you pair X is shorted to pair Y, etc, while some PHYs just tell you it
> is shorted. It also keeps the driver code simple. Report whatever you
> have in any order and it does not matter. And it means i don't need
> complex helper code trying to coordinating information from the
> driver.
>
> So far, a plain dump of the netlink message in user space also seems
> readable. But when we have more PHYs supported and more variability
> between PHYs we might need to consider if user space should do some
> sorting before printing the test results.
OK, if it would make driver code more complicated, let's keep it like
this. But it's still a bit unclear what exactly does the structure look
like as the example does not seem to match the enums below; I'll have to
take a look at the code composing the messages.
> > > +enum {
> > > + ETHTOOL_A_CABLE_PAIR_0,
> > > + ETHTOOL_A_CABLE_PAIR_1,
> > > + ETHTOOL_A_CABLE_PAIR_2,
> > > + ETHTOOL_A_CABLE_PAIR_3,
> > > +};
> >
> > Do we really need this enum, couldn't we simply use a number (possibly
> > with a sanity check of maximum value)?
>
> They are not strictly required. But it helps with consistence. Are the
> pairs numbered 0, 1, 2, 3, or 1, 2, 3, 4?
OK, I'm not strictly opposed to it, it just felt a bit weird.
> > > +enum {
> > > + ETHTOOL_A_CABLE_RESULT_UNSPEC,
> > > + ETHTOOL_A_CABLE_RESULT_PAIR, /* u8 ETHTOOL_A_CABLE_PAIR_ */
> > > + ETHTOOL_A_CABLE_RESULT_CODE, /* u8 ETHTOOL_A_CABLE_RESULT_CODE_ */
> > > +
> > > + __ETHTOOL_A_CABLE_RESULT_CNT,
> > > + ETHTOOL_A_CABLE_RESULT_MAX = (__ETHTOOL_A_CABLE_RESULT_CNT - 1)
> > > +};
> > > +
> > > +enum {
> > > + ETHTOOL_A_CABLE_FAULT_LENGTH_UNSPEC,
> > > + ETHTOOL_A_CABLE_FAULT_LENGTH_PAIR, /* u8 ETHTOOL_A_CABLE_PAIR_ */
> > > + ETHTOOL_A_CABLE_FAULT_LENGTH_CM, /* u16 */
> >
> > The example above says "u8" (which is obviously wrong).
>
> Yep, will fix that.
>
> > I would rather suggest u32 here to be as future proof as possible.
>
> Yes, i've been going backwards and forwards on that. I did not realize
> netlink messages were space inefficient. A u8 takes as much space as a
> u32. I picked u16 because that allows up 65535cm, or 655.35m. All the
> IEEE 802.3 Base-T standards have a maximum cable length of 100m, or
> shorter. They might work with longer cables, but i doubt a cable 6
> times longer than the specified max will work. So a u16 is ample.
>
> The only argument i can see for a u32 is if somebody can implement
> cable testing for fibre optical cables. Then a u16 is not big enough.
> But so far, i've never seen an SFP module offering this.
The problem is that this is UAPI which is "cast in stone". Thus we
should ask "Can I imagine someone implementing this in next 10-20
years?" rather than "Is there a real life hardware implementing this?".
Switching from u16 to u32 in internal kernel API may be a headache if
there are many drivers using it but switching from u16 to u32 in UAPI is
out of question so that we would have to resort to a workaround like
adding another attribute for "long fault length".
Michal
>
> > One more idea: it would be IMHO useful to also send a notification when
> > the test is started. It could be distinguished by a status attribute
> > which would describe status of the test as a whole (not a specific
> > pair), e.g. started, finished, aborted.
>
> Yes, give how long these tests take, i could be useful. There is also
> already some hints about this, in that the last patch in the series
> changes the RFC 2863 status of the interface, which i hope sends a
> message to user space about the interface change of status.
>
> Andrew
next prev parent reply other threads:[~2020-04-27 7:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 18:06 [PATCH net-next v1 0/9] Ethernet Cable test support Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 1/9] net: phy: Add cable test support to state machine Andrew Lunn
2020-04-26 19:46 ` Michal Kubecek
2020-04-26 20:31 ` Andrew Lunn
2020-04-26 21:22 ` Florian Fainelli
2020-04-25 18:06 ` [PATCH net-next v1 2/9] net: phy: Add support for polling cable test Andrew Lunn
2020-04-25 19:49 ` Florian Fainelli
2020-04-25 20:10 ` Andrew Lunn
2020-04-26 21:19 ` Florian Fainelli
2020-04-26 22:07 ` Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 3/9] net: ethtool: netlink: Add support for triggering a " Andrew Lunn
2020-04-26 19:36 ` Michal Kubecek
2020-04-26 20:38 ` Andrew Lunn
2020-04-26 20:50 ` Michal Kubecek
2020-04-25 18:06 ` [PATCH net-next v1 4/9] net: ethtool: Add attributes for cable test reports Andrew Lunn
2020-04-25 20:00 ` Randy Dunlap
2020-04-26 20:25 ` Michal Kubecek
2020-04-26 21:12 ` Andrew Lunn
2020-04-27 7:13 ` Michal Kubecek [this message]
2020-04-29 16:16 ` Michael Walle
2020-04-29 18:57 ` Andrew Lunn
2020-04-29 18:58 ` Florian Fainelli
2020-04-29 19:32 ` Michael Walle
2020-04-25 18:06 ` [PATCH net-next v1 5/9] net: ethtool: Make helpers public Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 6/9] net: ethtool: Add infrastructure for reporting cable test results Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 7/9] net: ethtool: Add helpers for reporting " Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 8/9] net: phy: marvell: Add cable test support Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 9/9] net: phy: Put interface into oper testing during cable test Andrew Lunn
2020-04-29 16:02 ` [PATCH net-next v1 0/9] Ethernet Cable test support Michael Walle
2020-04-29 16:32 ` Andrew Lunn
2020-04-30 17:48 ` Michael Walle
2020-04-30 18:23 ` Andrew Lunn
2020-04-30 19:44 ` Michael Walle
2020-04-30 20:51 ` Andrew Lunn
2020-04-30 18:34 ` Florian Fainelli
2020-04-30 19:31 ` Michael Walle
2020-04-30 19:38 ` Florian Fainelli
2020-04-30 19:52 ` Michael Walle
2020-04-30 19:41 ` Andrew Lunn
2020-04-30 20:01 ` Michael Walle
2020-04-30 20:56 ` Andrew Lunn
2020-04-30 20:04 ` Florian Fainelli
2020-04-30 20:13 ` Michael Walle
2020-04-30 20:19 ` Florian Fainelli
2020-04-30 21:16 ` Michael Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200427071324.GA9038@lion.mk-sys.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).