Re: [RFC] net: towards a generic PON framework

[Benjamin Larsson <benjamin.larsson@genexis.eu>]

Hi.

On 26/09/2026 19:46, Gaoyang Wei wrote:
> [You don't often get email from yhyxwgy@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi all,
> 

[...]

Most things should reuse already existing kernel infrastructure with 
modifications where needed.

What is completely new is the omci part. And here I have come to the 
opinion that some parts (MIBs) should be handled internally by the 
kernel and some should/can only be handled by user space. Because of 
that there needs to be some kind of api where you can connect the user 
space version of the omci stack to the kernel level ploam transport 
(gpon inband side channel).

Doing it this way gives the advantage of not needing an external omci 
stack for some OLTs which is nice for development and testing purposes 
amongst other things. But interoperability amongst OLTs is really bad so 
there also needs to be a flexible way to just update the omci part in 
case you really need to amend the omci logic. (Omci is used to negotiate 
the data path).

The api also needs a way to monitor the messages sent back and forth to 
be able to triage issues. This is a common issue in pon deployments.


> 
> Questions
> =========
> 
> I would particularly appreciate feedback on the following points:
> 
> 1. Does Linux need a struct pon_device or equivalent at all, or can
>     the required concepts be represented by existing networking
>     objects?

The gpon mac data transport should expose an ethernet networking 
interface but the model for the ploam transport does not need to be one.

> 
> 2. If there is a generic PON object model, how much should it expose?
>     Are T-CONT, GEM, and LLID appropriate generic objects, or are they
>     too close to individual protocols or hardware implementations?

Does the kernel really need to handle all this? Is it not enough to just 
handle the omci interface and data pass through? At least this is the 
model we should have in an initial implementation.

> 
> 3. Should OMCI management PDUs be represented by a packet-oriented
>     interface?  If so, is a dedicated net_device appropriate?

-

> 
> 4. Should PLOAM/MPCP activation remain driver-specific, with only
>     common line state exposed by a generic layer?

Ploam is realtime and need fast handling of ploam messages, I have 
observed link failures because of debug output printing to console, 
handling it in generic code would risk exposing timing issues, it 
belongs in the hardware mac driver that then should expose the omci 
interface. That part should be common code.

> 
> 5. What should the interface between a PON MAC and fixed optical
>     frontends look like, and how much should be shared with SFP,
>     phylink, PHY, hwmon, and thermal infrastructure?
> 

Unfortunately the Econet/Airoha LDDLAs deviates from SFF-8472. So 
regarding those one option could be to create a wrapper that makes them 
look like a sfp module that you then could virtually plug into a port. 
But later on I started to change my mind and that we should model them 
what they really are. And that is as a BoB (Bi-Directional Optical 
Sub-Assembly on Board). Something very related to the sfp module but 
maybe called bob instead because that is what it is.

> 6. How should classification into GEM/LLID bearers interact with TC
>     and existing hardware-offload APIs?

As I see it we should keep everything in the ethernet domain and adapt 
the PON configuration around it, at least to start with.

> 
> 7. How much should the ITU-T PON family and IEEE EPON family share in
>     one object model?  It would be useful to avoid both
>     protocol-specific private APIs and an abstraction so generic that
>     it no longer represents the hardware usefully.

-

> 
> 8. Which configuration belongs in a networking control API
>     (rtnetlink, Generic Netlink, etc.), and which state should only be
>     observable through existing kernel subsystems?
> 

-

> Next steps
> ==========
> 
> I am intentionally not proposing a UAPI or struct definitions in this
> mail.
> 
> There is working code which can be used as a reference implementation,
> but I would prefer to get agreement on the subsystem boundary before
> turning one vendor implementation into an API which other PON drivers
> would later have to follow.
> 
> If the overall direction makes sense, the next step could be a small
> RFC patch series containing only the minimum generic model together
> with one real hardware consumer, rather than attempting to upstream a
> complete PON stack at once.
> 
> I would also be very interested in hearing from developers working on
> non-Airoha PON hardware.  A second independent hardware family would
> be particularly useful for determining whether any proposed
> abstraction is genuinely generic rather than an Airoha interface with
> generic names.
> 
I think a good way to start is with the dts and see how things end up 
and then create a RFC around that.

MvH
Benjamin Larsson