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

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Benjamin,

Thanks, this is very helpful.

 > 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).

I think this is an important point.

The more implementations we compare, the less convinced I am that the
generic framework should decide up front where the complete G.988
agent has to live.

The AN7581/AN7583 implementation keeps the G.988 model in userspace,
while Matheus has a largely in-kernel implementation, and what you
describe sounds like a hybrid model.

That makes me think the generic boundary should probably separate:

         PON MAC / activation / transport
                     |
              OMCI transport
                     |
         +-----------+-----------+
         |                       |
    in-kernel handling      userspace OMCI
         |                       |
         +-----------+-----------+
                     |
               GEM/T-CONT /
               service setup

rather than making "OMCI is in kernel" or "OMCI is in userspace" part
of the driver model itself.

In other words, perhaps the common part should expose the OMCC
transport and the hardware operations needed by OMCI, while allowing
the actual ME/MIB logic to be split differently by different
implementations.

 > 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.

This matches what we have been seeing as well.

I think the interoperability argument is particularly important here.
Even if a kernel implementation handles the common G.988 cases, there
needs to be a way to replace or extend the higher-level OMCI behaviour
without having to modify the kernel for every OLT/vendor quirk.

That also suggests that the kernel-facing API should operate on fairly
low-level semantic objects and raw OMCI messages, rather than exposing
the full G.988 managed-entity model as a stable UAPI.

 > 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.

Agreed.

This is also one reason we have been looking at a packet-oriented OMCI
endpoint.  Independently of the exact API, I think observability should
be treated as a first-class requirement.

For interoperability debugging we want to be able to inspect the
actual request/response sequence, including vendor-specific MEs and
unexpected result codes, rather than only seeing the final configured
state.

Andrew has raised the question of whether a dedicated management
net_device is the right abstraction, so we are discussing that
separately.  But I think your point means that whichever transport we
choose, it should have a natural way to observe the raw OMCI exchange.

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

I agree with that separation.

The normal service datapath should remain an ordinary Ethernet
net_device.

PLOAM is different: it belongs to the PON MAC state machine and does
not represent an Ethernet data path.

 > 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.

I think this is probably a good way to reduce the scope of the first
RFC patch series.

Rather than immediately introducing generic kernel objects for every
T-CONT, GEM port, LLID and service relationship, an initial framework
could perhaps contain only:

         - a PON device / line object;
         - line mode and activation state;
         - the normal Ethernet service datapath;
         - the OMCI transport hook;
         - the optical frontend relationship.

Then T-CONT/GEM/LLID objects would only be added once we have a real
cross-driver operation which requires them.

That would avoid turning one vendor's internal resource model into the
generic Linux model too early.

 > 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.

This is very useful implementation experience.

I agree that the timing-sensitive PLOAM FSM should remain in the MAC
driver, especially if even printk latency can disturb activation.

What I would still like the generic layer to expose is only the stable
semantic state resulting from that FSM, for example:

         O1/O2/O3/O4/O5-like activation state
         ONU-ID assigned / not assigned
         OMCC available / unavailable
         loss of signal / loss of frame

rather than trying to implement the actual timing-sensitive PLOAM
message handling in common code.

Do you think that is a reasonable split?

 > 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).

I think modelling it as what it actually is is probably cleaner as
well.

The parts which already map to existing subsystems can still use them,
for example hwmon for optical telemetry and NVMEM for calibration,
without requiring the complete device to pretend to be an SFP module.

A small BoB/optical-frontend object could then provide only the
operations which are genuinely needed by the PON MAC, such as TX
enable, burst re-arm and optical state.

That seems preferable to synthesising SFF-8472 data which does not
really exist in the hardware.

 > I think a good way to start is with the dts and see how things end up
 > and then create a RFC around that.

I would be interested in what you would put into the initial DT model.

My current thought is that DT should describe hardware topology, for
example:

         PON MAC
           |
         xPON PHY
           |
         fixed BoB / LDDLA

plus calibration/NVMEM relationships and any fixed GPIO/regulator
connections.

I would be more cautious about putting ONU identity or operator policy
into DT, since values such as serial number, LOID, OMCI vendor ID or
OLT-specific profiles may come from NVMEM, be derived, or be supplied
by userspace.

If that is also what you mean by starting from DTS, then I think it
could be a useful way to establish the hardware object boundaries
before defining any UAPI.

So at the moment I am leaning towards an intentionally small first
step:

         driver-specific PLOAM / MPCP FSM
                      |
              minimal generic PON object
                      |
           +----------+----------+
           |                     |
      Ethernet data          OMCI transport
         netdev                  |
                                 |
                      kernel and/or userspace
                          OMCI implementation

with the optical frontend represented separately and existing Linux
subsystems reused where possible.

Does that match the boundary you have in mind?

Thanks,
Gaoyang