Adding IEEE802.3cg Clause 148 PLCA support to Linux

Adding IEEE802.3cg Clause 148 PLCA support to Linux

[piergiorgio.beruto]

Hello,
I would like to add IEEE 802.3cg-2019 PLCA support to Linux.
PLCA (Physical Layer Collision Avoidance) is an enhanced media-access protocol for multi-drop networks, and it is currently specified for the 10BASE-T1S PHY defined in Clause 147 of the same standard.
This feature is fully integrated into PHY and MACPHY implementations such as the onsemi NCN26010 and Microchip LAN867x, which are available on the market.
And, I am the inventor of the PLCA protocol 😊.

I am writing here because I am seeking advice on what is the best way forward.
In practice, what we need to do is configuring some additional parameters of the PHY: PLCA ID, TO_TIMER, NODE_COUNT, BURST.
The PHY registers for PLCA configuration are further documented in the OPEN alliance SIG public specifications (see https://www.opensig.org/about/specifications/ -> PLCA Management Registers)

The parameters I mentioned has to be configured dynamically. Therefore, I think we should not use module parameters or static DT configurations.
Based on my personal experience, It looks to me that extending ethtool is the way to go. Maybe we should consider those as “tunables”?

I am really interested to hear the opinion of the relevant Linux network experts on this topic.

Kind Regards,
Piergiorgio

Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[Andrew Lunn]

On Sat, Nov 05, 2022 at 06:42:10PM +0100, piergiorgio.beruto@gmail.com wrote:
> Hello,
> I would like to add IEEE 802.3cg-2019 PLCA support to Linux.

Could you recommend any introductory document? 802.3 can be heavy
going.

> PLCA (Physical Layer Collision Avoidance) is an enhanced
> media-access protocol for multi-drop networks, and it is currently
> specified for the 10BASE-T1S PHY defined in Clause 147 of the same
> standard.

> This feature is fully integrated into PHY and MACPHY implementations
> such as the onsemi NCN26010 and Microchip LAN867x, which are
> available on the market.

Do the MAC and PHY need to negotiate this feature? Does the MAC need
to know if the PHY is PLCA capable? Ideally,
genphy_c45_pma_read_abilities() can determine if a PHY is PLCA
capable? And the MAC can then check the result of this and enable its
part of PLCA?

> In practice, what we need to do is configuring some additional
> parameters of the PHY: PLCA ID, TO_TIMER, NODE_COUNT, BURST.

Are these purely PHY configuration values? Is the MAC involved at all?

> The PHY registers for PLCA configuration are further documented in
> the OPEN alliance SIG public specifications (see
> https://www.opensig.org/about/specifications/ -> PLCA Management
> Registers)

Nice. But do the available PHYs actually follow this? Ideally you
should provide a set of helpers which implement these registers. But
you have to assume that silicon vendors will ignore the standard and
implement it differently. They often do. So the helpers are just
helpers, and the PHY driver needs to be able to implement these values
in there own way.

> The parameters I mentioned has to be configured dynamically.

How dynamically? And what is setting them? Do you see the need for a
user space daemon? Are values placed in /etc/network/interfaces?

Ethtool does seems like one option. But i would like to understand the
bigger picture before making a definitive answer.

       Andrew

RE: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[piergiorgio.beruto]

Hello Andrew,
Thank you for your kind reply.

Please see my answers interleaved below.

Kind Regards,
Piergiorgio

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch> 
Sent: 6 November, 2022 00:41
To: piergiorgio.beruto@gmail.com
Cc: netdev@vger.kernel.org
Subject: Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

On Sat, Nov 05, 2022 at 06:42:10PM +0100, piergiorgio.beruto@gmail.com
wrote:
>> Hello,
>> I would like to add IEEE 802.3cg-2019 PLCA support to Linux.

> Could you recommend any introductory document? 802.3 can be heavy going.

The 10BASE-T1S specifications span over Clauses 147 and 148. 802.3cg is an
amendment over 802.3 adding these clauses and further amending Clause 22, 45
and 30. Please, be aware that 802.3cg amends more clauses related to
10BASE-T1L (long-reach, point-to-point PHY), T1 autoneg and power over data
lines. However, these are not in scope for 10BASE-T1S and PLCA. The standard
is relatively new (2019) therefore there isn't a lot of whitepapers
available yet.
I can recommend presentations posted on the IEEE 802.3cg website
(https://www.ieee802.org/3/cg/). This one is contains a general overview of
PLCA: https://www.ieee802.org/3/cg/public/July2018/PLCA%20overview.pdf.
I can also send you a few presentations on a separate e-mail.
Finally, I'm drafting a Wikipedia page on T1S
(https://en.wikipedia.org/wiki/Draft:10BASE-T1S) but it is really work in
progress.

>> PLCA (Physical Layer Collision Avoidance) is an enhanced media-access 
>> protocol for multi-drop networks, and it is currently specified for 
>> the 10BASE-T1S PHY defined in Clause 147 of the same standard.

>> This feature is fully integrated into PHY and MACPHY implementations 
>> such as the onsemi NCN26010 and Microchip LAN867x, which are available 
>> on the market.

> Do the MAC and PHY need to negotiate this feature? Does the MAC need to
know if the PHY is PLCA capable? Ideally,
> genphy_c45_pma_read_abilities() can determine if a PHY is PLCA capable?
And the MAC can then check the result of this and enable its part of PLCA?

PLCA was intentionally designed NOT to change the MAC. It is similar to EPON
in this regard (but way simpler). So the straight answer is no, the MAC does
not need to know that the PHY is PLCA capable.
However, PLCA can only work if the MAC supports half-duplex mode.
PLCA support can be tested by probing dedicated registers. Unfortunately,
because of "political/philosophical" fights we could not specify the PLCA
registers in Standard Clause 45 at the time the standard was sent for
review. This is why we ended up having a separate document. We do have
Clause 30 parameters, which maps directly to the registers defined in the
OPEN Alliance.

IMPORTANT: if you look at the IEEE specifications, the PLCA RS is defined to
be on top of the MII interface (but still below the MAC, in the Physical
layer). This is due to how the IEEE layering is structured, but it is NOT
how everybody implements PLCA. As I said, the intention was not to require
modifications to the MAC. You can see this explained in
https://www.ieee802.org/3/cg/public/July2018/PLCA%20overview.pdf and
https://www.ieee802.org/3/cg/public/Jan2019/Tutorial_cg_0119_final.pdf. In
short, there is an "internal" MII between the RS and the PCS layers, plus an
exposed MII which connects to the MAC (formally it is an implementation of
Clause 4 and 6 primitives that matches the existing MII interface). This
external MII allows to connect to any MAC, In fact, it was tested
successfully even against MAC belonging to 1990's.

>> In practice, what we need to do is configuring some additional 
>> parameters of the PHY: PLCA ID, TO_TIMER, NODE_COUNT, BURST.

> Are these purely PHY configuration values? Is the MAC involved at all?
They are PHY attributes, the MAC is unaware of the underlying PLCA layer.

>> The PHY registers for PLCA configuration are further documented in the 
>> OPEN alliance SIG public specifications (see 
>> https://www.opensig.org/about/specifications/ -> PLCA Management
>> Registers)

> Nice. But do the available PHYs actually follow this? Ideally you should
provide a set of helpers which implement these registers. But you have to
assume that silicon vendors will ignore the standard and implement it
differently. They often do. So the helpers are just helpers, and the PHY
driver
> needs to be able to implement these values in there own way.

The Si vendors are actually following this specification. I work for one of
those companies, and you can see that implemented in these datasheets:
https://www.onsemi.com/download/data-sheet/pdf/ncn26010-d.pdf
https://ww1.microchip.com/downloads/aemtest/AIS/ProductDocuments/DataSheets/
DS-LAN8670-1-2-60001573C.pdf
I am also personally aware of more implementations that are coming to the
market from different suppliers and they are all going to follow this
standard.  In fact, it is required by our customers and there is just no
reason not to follow those.
Just to cite an example, during the automotive Ethernet congress in Munich
(June 2022) there was a big show where products from Analog Devices, Marvell
and others have been demonstrated and tested for interoperability. All of
those are OPEN compliant.

>> The parameters I mentioned has to be configured dynamically.

> How dynamically? And what is setting them? Do you see the need for a user
space daemon? Are values placed in /etc/network/interfaces?

At the moment, the actual method for setting these parameters is not
mandated by the standard. In my understanding, people will use different
approaches based on their application. For engineered networks, they will
likely be set according to some HW configuration (EEPROM, GPIOs, board
slot/connector, switch port, etc.). In other use cases, the network will
start in "normal" CSMA/CD mode to negotiate the PLCA configuration using
LLDP and/or DHCP.

So, back to your questions, I don't really know yet. I believe we are going
to have different approaches, some of which may require a user-space daemon.
But eventually, everything comes down to writing the appropriate values in
the PHY registers. For a start, that will be sufficient.
I don't mean to create confusion, but there is another standard,
IEEE802.3da, that is further extending PLCA to implement a fully automated
way to assign the PLCA IDs in HW (we call this D-PLCA). However, it is still
work in progress and I'd rather not mix the two things here and now.
Existing products implement PLCA, not D-PLCA. I mentioned this just to give
you the bigger picture.

> Ethtool does seems like one option. But i would like to understand the
bigger picture before making a definitive answer.
Sure, I totally understand. And I'll be happy to answer any question you
might have.

       Andrew

Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[Andrew Lunn]

> Based on my personal experience, It looks to me that extending
> ethtool is the way to go. Maybe we should consider those as
> “tunables”?

I suggest you define new ethtool netlink messages. I don't think PHY
tunables would make a good interface, since you have multiple values
which need configuring, and you also have some status information.

So you probably want a message to set the configuration, and another
to get the current configuration. For the set, you probably want an
attribute per configuration value, and allow a subset of attributes to
be included in the message. The get configuration should by default
return all the attributes, but not enforce this, since some vendor
will implement it wrong and miss something out.

The get status message should return the PST value. This is something
you might also want to append to the linkstate message, next to the
SQI values.

What i don't see in the Open Alliance spec is anything about
interrupts. It would be interesting to see if any vendor triggers an
interrupt when PST changes. A PHY which has this should probably send
a linkstate message to userspace reporting the state change. For PHYs
without interrupts, phylib will poll the read_status method once per
second. You probably want to check the PST bit during that poll. If EN
is true, but PST is false, is the link considered down?

I would also include a check in the phylib core. If the set request
tries to set EN to true, check the current link mode and if it is not
half duplex return -EINVAL. An extack messages would be good here as
well.

For the interface between phylib and the PHY driver, you should
probably add to the struct phy_driver a set configuration method, a
get configuration method, and maybe a get status method. You can
provide implementations for these methods in phy-c45.c which any PHY
driver which conforms to the standard can use.

    Andrew

RE: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[piergiorgio.beruto]

> I suggest you define new ethtool netlink messages. I don't think PHY tunables would make a good interface, since you have > multiple values which need configuring, and you also have some status information.

That sounds fair to me, thanks for your advice.

> So you probably want a message to set the configuration, and another to get the current configuration. For the set, you 
> probably want an attribute per configuration value, and allow a subset of attributes to be included in the message. The get 
> configuration should by default return all the attributes, but not enforce this, since some vendor will implement it wrong 
> and miss something out.

Yes, that sounds about right. If you have any hint on where in the code to start looking at, I'll start from there.

> The get status message should return the PST value. This is something you might also want to append to the linkstate 
> message, next to the SQI values.

Sure.

> What I don't see in the Open Alliance spec is anything about interrupts. It would be interesting to see if any vendor triggers 
> an interrupt when PST changes. A PHY which has this should probably send a linkstate message to userspace reporting the 
> state change. For PHYs without interrupts, phylib will poll the read_status method once per second. You probably want to 
> check the PST bit during that poll. If EN is true, but PST is false, is the link considered down?

This is actually an interesting point. First of all, yes, vendors do have IRQs for the PST. At least, the products I'm working on do, including the already released NCN26010.

My thinking is that the PST should be taken into account to evaluate the status of the link. On a multi-drop network with no autoneg and no link training the link status would not make much sense anyway, just like the connected status of an UDP socket wouldn't make sense.

My thinking is that we should enable the PHY drivers to report a link status evaluating PST as well.

> I would also include a check in the phylib core. If the set request tries to set EN to true, check the current link mode and if it
> is not half duplex return -EINVAL. An extack messages would be good here as well.

Yes, that makes sense.

> For the interface between phylib and the PHY driver, you should probably add to the struct phy_driver a set configuration 
> method, a get configuration method, and maybe a get status method. You can provide implementations for these methods 
> in phy-c45.c which any PHY driver which conforms to the standard can use.

Roger, thanks for the hint!

Piergiorgio

Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[Andrew Lunn]

On Sun, Nov 06, 2022 at 07:11:32PM +0100, piergiorgio.beruto@gmail.com wrote:
> > I suggest you define new ethtool netlink messages. I don't think PHY tunables would make a good interface, since you have > multiple values which need configuring, and you also have some status information.

Your email client is messing up emails. I follow the netique rules, my
lines are wrapped at around 75 characters. This is recommended
practice for all Linux kernel mailing lists. Your mailer has destroyed
this. Please also wrap your own text at about 75 characters.

> That sounds fair to me, thanks for your advice.
> 
> > So you probably want a message to set the configuration, and another to get the current configuration. For the set, you 
> > probably want an attribute per configuration value, and allow a subset of attributes to be included in the message. The get 
> > configuration should by default return all the attributes, but not enforce this, since some vendor will implement it wrong 
> > and miss something out.
> 
> Yes, that sounds about right. If you have any hint on where in the code to start looking at, I'll start from there.

ethtool --cable-test packs a number of optional attributes into a
netlink message. It then gets passed to phylib. You could use that as
an example. The way cable tests results are passed back later is
pretty unusual, so don't copy that code!

> > What I don't see in the Open Alliance spec is anything about interrupts. It would be interesting to see if any vendor triggers 
> > an interrupt when PST changes. A PHY which has this should probably send a linkstate message to userspace reporting the 
> > state change. For PHYs without interrupts, phylib will poll the read_status method once per second. You probably want to 
> > check the PST bit during that poll. If EN is true, but PST is false, is the link considered down?
> 

> This is actually an interesting point. First of all, yes, vendors do have IRQs for the PST. At least, the products I'm working on do, including the already released NCN26010.

Each PHY driver is going to need its own code for enabling the
interrupt, handling etc, since none of this is standardized. This is
one reason why you provide helpers, but don't force there use.

> My thinking is that the PST should be taken into account to evaluate the status of the link. On a multi-drop network with no autoneg and no link training the link status would not make much sense anyway, just like the connected status of an UDP socket wouldn't make sense.

So the read_status() call should evaluate the PST bit, along with
EN. Again, a helper to do that would be useful.

The user API is the most important bit of this work. Linux considers
the uAPI an stable ABI. Once you have defined it, it cannot change in
ways which break backwards compatibility. So the initial reviews of
code you present will concentrate on the uAPI. Once that is good,
reviews will then swap to all the implementation details in phylib and
the drivers.

    Andrew

Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

[Oleksij Rempel]

Hi Piergiorgio,

please CC me for the next rounds of T1* related topics :)


On Sun, Nov 06, 2022 at 08:05:51PM +0100, Andrew Lunn wrote:
> On Sun, Nov 06, 2022 at 07:11:32PM +0100, piergiorgio.beruto@gmail.com wrote:
> > > I suggest you define new ethtool netlink messages. I don't think PHY tunables would make a good interface, since you have > multiple values which need configuring, and you also have some status information.
> 
> Your email client is messing up emails. I follow the netique rules, my
> lines are wrapped at around 75 characters. This is recommended
> practice for all Linux kernel mailing lists. Your mailer has destroyed
> this. Please also wrap your own text at about 75 characters.
> 
> > That sounds fair to me, thanks for your advice.
> > 
> > > So you probably want a message to set the configuration, and another to get the current configuration. For the set, you 
> > > probably want an attribute per configuration value, and allow a subset of attributes to be included in the message. The get 
> > > configuration should by default return all the attributes, but not enforce this, since some vendor will implement it wrong 
> > > and miss something out.
> > 
> > Yes, that sounds about right. If you have any hint on where in the code to start looking at, I'll start from there.
> 
> ethtool --cable-test packs a number of optional attributes into a
> netlink message. It then gets passed to phylib. You could use that as
> an example. The way cable tests results are passed back later is
> pretty unusual, so don't copy that code!
> 
> > > What I don't see in the Open Alliance spec is anything about interrupts. It would be interesting to see if any vendor triggers 
> > > an interrupt when PST changes. A PHY which has this should probably send a linkstate message to userspace reporting the 
> > > state change. For PHYs without interrupts, phylib will poll the read_status method once per second. You probably want to 
> > > check the PST bit during that poll. If EN is true, but PST is false, is the link considered down?
> > 
> 
> > This is actually an interesting point. First of all, yes, vendors do have IRQs for the PST. At least, the products I'm working on do, including the already released NCN26010.
> 
> Each PHY driver is going to need its own code for enabling the
> interrupt, handling etc, since none of this is standardized. This is
> one reason why you provide helpers, but don't force there use.
> 
> > My thinking is that the PST should be taken into account to evaluate the status of the link. On a multi-drop network with no autoneg and no link training the link status would not make much sense anyway, just like the connected status of an UDP socket wouldn't make sense.
> 
> So the read_status() call should evaluate the PST bit, along with
> EN. Again, a helper to do that would be useful.
> 
> The user API is the most important bit of this work. Linux considers
> the uAPI an stable ABI. Once you have defined it, it cannot change in
> ways which break backwards compatibility. So the initial reviews of
> code you present will concentrate on the uAPI. Once that is good,
> reviews will then swap to all the implementation details in phylib and
> the drivers.
> 
>     Andrew

Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |