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

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Matheus,

Thanks, this is exactly the kind of second implementation I was hoping
to compare against.

 > in my implementation part I have a system controlled by the kernel,
 > without userspace for OMCI, everything being handled and controlled
 > by the kernel

This is particularly interesting because it gives us two working
design points with a very different kernel/userspace split.

The AN7581/AN7583 implementation keeps the G.988 MIB and service graph
in userspace, while your implementation places the OMCI agent, MIB,
ME handling and service graph in net/xpon/omci.

I think this is probably one of the most important questions for this
RFC.

Could you describe what led you to keep the G.988 model in the kernel?

In particular, I would be interested in whether there are operations
which require sufficiently tight coupling with the PLOAM/GEM state
that a userspace OMCI agent becomes impractical, or whether the main
reason is architectural simplicity and having one kernel-controlled
state machine.

I am also wondering whether the transport and the OMCI implementation
could be treated as two separate questions.

For example, could a generic xPON layer provide the OMCC transport and
GEM/T-CONT operations while allowing either:

   1. an in-kernel OMCI implementation, or
   2. a userspace OMCI implementation through a packet interface?

That might let us avoid deciding too early that every driver must use
the same OMCI architecture.

 > I'm creating two new subsystems to control LDDLA (optical) and xPON

The optical_frontend abstraction is also very relevant to Benjamin's
earlier RFC.

I think it would be useful to compare exactly which operations your
optical_frontend API needs against the existing PHY/SFP/hwmon
interfaces.

For example, I would expect:

   - temperature / voltage / bias / optical power -> hwmon
   - calibration storage -> NVMEM where applicable
   - LOS / TX enable / burst control -> frontend <-> PON MAC API

but I am less sure about protocol/wavelength configuration and where
that should live.

 > In total, I have tests on the Airoha en7523, en751221 and en7528

This is especially useful.

Having EN751221/EN7523/EN7528 in addition to AN7581/AN7583 gives us
more than one hardware generation to test the abstraction against.
I would very much like to identify which fields and operations are
actually common between them before defining a generic API.

Your DT example also raises another question.

The hardware relationships such as:

         phys = <&xpon_phy>;
         ethernet = <&gdm2>;
         optical-frontends = <&en7571>;

seem like natural DT topology.

On the other hand, properties such as:

         omci-vendor-id = "TPLG";
         airoha,gpon-serial-from-mac;

look more like ONU identity/provisioning policy than hardware
description to me.

I suspect those may be better supplied through NVMEM or userspace
configuration rather than becoming DT ABI, but this is another point
where upstream feedback would be useful.

Finally, your note that GEM/PVID/VLAN handling is performed by the
PSE/FE/QDMA is useful confirmation that the Ethernet classification
path and the PON bearer objects should probably not be conflated in
the generic model.

Thanks for posting the architecture and the DT examples.  This is
exactly the comparison I hoped this RFC would trigger.

Thanks,
Gaoyang Wei