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

[Ziyou Xu <xuziyougm@gmail.com>]

Hi Gaoyang,

I agree that the transport and the control API should probably be
considered separately.

I am wondering whether we need a Generic Netlink interface at all at
this stage.

If the immediate userspace requirement is only transporting raw OMCI
PDUs, AF_PACKET already provides that abstraction.  Other PON state
may remain internal to the kernel or be exposed through existing
subsystems until we have a concrete operation which requires a new
xPON-specific UAPI.

The reason I still see value in a net_device is not to model OMCI as
Ethernet, but to provide the packet endpoint required by AF_PACKET.

With an ARPHRD_NONE device, the interface could carry only raw OMCI
PDUs, without Ethernet headers, addressing, ARP, or Ethernet bridge
semantics.

There is also a practical debugging advantage to this model.

A packet endpoint gives us a natural capture point for
tcpdump/libpcap/Wireshark without having to introduce a second
debugging interface.  There are already Wireshark dissectors for
OMCI, for example:

   https://github.com/0liv1er/omci-wireshark-dissector

This is particularly useful for interoperability work.

Although G.988 specifies OMCI, deployed networks are often less
uniform than the base standard suggests.  Vendors and operators use
private managed entities, profiles, and behavioral quirks.

One example is China Telecom's LOID authentication extension, which
uses the private OMCI ME class 65530 (0xfffa).  Debugging this kind of
interoperability issue is much easier when the raw OMCI exchange can
be captured and decoded directly.

Using a packet-like netdev for OMCI is also not unique to the current
AN7581/AN7583 implementation.  There is precedent for this model in
vendor SDK/BSP implementations as well; the older Airoha SDK, for
example, also exposed OMCI through a netdev-like userspace path.

I do not think vendor precedent by itself is a reason to standardize
such an ABI, but it suggests that representing OMCI as a packet
channel maps reasonably well to existing hardware and driver designs.

Without a packet endpoint, we would need to define equivalent RX/TX,
delivery, and probably observability semantics through another
interface such as Generic Netlink.

I am not yet sure that buys us much if the only thing crossing the
kernel/userspace boundary is an opaque OMCI PDU.

So perhaps there are two questions:

   1. Is using a minimal non-Ethernet net_device purely as an
      AF_PACKET endpoint itself considered undesirable?

   2. If it is, what would be the preferred Linux-native transport for
      raw OMCI PDUs while retaining packet-level observability?

I think we should avoid defining a broader xPON Generic Netlink UAPI
until we have a concrete control operation which cannot be represented
cleanly by an existing interface.

Thanks,
Ziyou Xu