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

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Matheus,

Thanks, this makes the reasoning much clearer.

 > with tests on en7523 and en751221 with some users, I saw them
 > attaching the OMCI network interface within a bridge, and in order
 > not to expose this interface again to a user, I implemented my OMCI
 > within the kernel

Was that OMCI interface exposed as ARPHRD_ETHER?

I ask because I do not think a packet-oriented OMCI net_device would
need Ethernet semantics at all.

For example, it could use ARPHRD_NONE, have no synthetic L2 header,
and use IFF_NOARP / IFF_POINTOPOINT.  In that case it should not be a
valid device to enslave to an Ethernet bridge in the first place.

net_device itself is not synonymous with Ethernet.  CAN is another
example of a packet-oriented protocol exposed through net_device with
different link-layer semantics.

If the previous OMCI interface used ARPHRD_ETHER, then I wonder whether
the ability to bridge it was a property of that implementation rather
than a fundamental problem with representing OMCI as a net_device.

This would still leave the separate question of whether the G.988
agent itself belongs in kernel or userspace.

 > with this I also had less overhead in the ethernet system, and faster
 > responses to OLT due to the new implementation.

This is also interesting.

Do you have any measurements for the CPU overhead and OMCI response
latency before and after moving the agent into the kernel?

It would help distinguish costs inherent to a userspace OMCI design
from costs specific to the previous implementation.

I still think it may be useful to treat OMCC transport and OMCI agent
placement as two separate design questions.

For example, a generic xPON layer might provide 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 would avoid requiring every driver to make the same choice before
we know whether that choice is actually hardware-independent.

 > I am also aware of some Realtek SoCs having slightly different OMCI in
 > which my subsystems need to be adjusted to see this data, something
 > that fails in my current implementation

I think this is particularly useful evidence for keeping the generic
boundary small.

If Realtek requires different OMCI handling, that seems to strengthen
the case for separating common OMCC transport and PON hardware
operations from the policy of where the G.988 implementation lives.

 > The optical subsystem in which I implemented it already uses several
 > subsystems already present in Linux, so temperatures, bias and optical
 > power are already used within hwmon, for calibration I already use
 > nvmem to obtain the data and start LDDLA.

This is very close to what I had in mind.

Using hwmon for telemetry and NVMEM for calibration seems much cleaner
than exposing those through a PON-specific userspace ABI.

The remaining part I would like to understand better is the generic API
between the PON MAC and the fixed optical frontend, especially for:

   - LOS;
   - TX enable;
   - burst enable / rearm;
   - protocol and rate selection;
   - wavelength selection where applicable.

I think this is also where Benjamin's earlier BOSA/SFP discussion is
directly relevant, and I would like to hear what the PHY/phylink/SFP
maintainers think before suggesting a concrete API.

 > a good part of the subsystem depends on values coming from the
 > userspace, that's why we wrote a generic netlink and sysfs for
 > userspace communication

That also makes sense.

For ONU identity in particular, I still think it is worth separating
hardware description from provisioning policy.

Some values may come from NVMEM, some may be derived from other device
identity, and some may be supplied by userspace.  I am therefore not
sure that values such as an OMCI vendor ID should become part of the DT
ABI unless they really describe immutable hardware properties.

I will spend some time reading through the implementation you posted.

At this point I think we have two useful implementation models:

   - kernel PON MAC + userspace G.988;
   - kernel PON MAC + in-kernel G.988.

That is a good basis for identifying which parts are genuinely generic
and which parts should remain implementation choices.

Thanks,
Gaoyang