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

[John Crispin <john@phrozen.org>]

Hi all,

Christian Marangi has been working on the design of a PON subsystem
together with Airoha for almost a year. I started implementing it on
the AN7581 two months ago. Reading this thread was a bit of a
surprise, because the design you are converging on is very close to
what we already have running and were planning to propose upstream in
the near future. So rather than add another design on paper, let me
describe working code.

The design is modelled on nl80211/cfg80211 with a fullmac driver.

net/pon has a struct pon_dev for each PON MAC. It is not a netdev,
which is what Andrew described with the wiphy comparison. Userspace
talks to it by a device id, not an ifindex.

The MAC driver runs PLOAM and the key hierarchy itself, as Benjamin
suggests. It reports the activation state to the core. The core checks
it, publishes it together with the alarms and sets carrier from it.

Service traffic uses normal netdevs. There is one data netdev, plus
GEM netdevs where a GEM port needs its own bridge port. Frames leave
through a GDM port of the Ethernet driver, which acts as a conduit in
the DSA sense.

Andrew's mapper exists too. A classifier on the data netdev maps
VLAN and 802.1p to GEM ports. The core keeps the T-CONTs, the GEM
ports and these rules. It replays them after a link loss. Everything
above that is plain bridge, VLAN devices and tc. T-CONT scheduling is
an offloaded ets qdisc.

The design reuses existing infrastructure wherever it can. The optics
report through hwmon and take their calibration from NVMEM. The PON
serdes is a generic PHY. The PHY core only needed a PHY_MODE_PON and a
set of PON configure options. Sync status, FEC counters and three
reports (ready, loss, TX fault) go through a small PON side channel.
That could become part of the PHY core, but that is a problem for
another day.

Control is a single generic netlink family with a YAML spec. OMCI runs
in userspace, in a GPL daemon that sets up the PON objects over that
family and everything Ethernet over bridge, tc, ethtool and rtnetlink.

There is also a small command line tool, pon-tool, which plays the
role iw plays for nl80211. It has a verb for every attribute of the
family, so the whole subsystem can be inspected and driven by hand.
It dumps the device, T-CONTs, GEM ports, classifier rules, counters
and alarms. A monitor mode follows the PLOAM state, alarms and object
changes live. GEM netdevs are created over rtnetlink with their own
link kind, the same way iw creates wireless interfaces.

The current code reaches O5, passes traffic and survives fibre pulls
against a production OLT. I have successfully tested HGU, SFU and IP
host services running concurrently. PON flows are also offloaded in
hardware through the Airoha PPE and NPU.

On the OMCI transport I think Andrew is right that omci0 has to go.
Today it is an ARPHRD_NONE conduit used with AF_PACKET, which is an
interface that is not really an interface. Rather than add a new
address family, I would follow what hostapd and wpa_supplicant do.
Wifi once relied on a monitor interface for management frames. It
moved to frame registration, TX and RX over generic netlink. The PON
family would get the same: a daemon registers for OMCI on a PON
device and receives and sends PDUs as netlink messages. That keeps
the subsystem on the design that already works for wifi and needs no
new address family. The core already knows which GEM port carries
the OMCC, so there is nothing to classify.

Benjamin, you wrote that some parts of the MIB should be handled
inside the kernel. Which MEs do you have in mind? The OMCC transport
belongs to the core, so an in-kernel handler could attach to it. I
would like to understand which MEs need it before we design for it.

If all of this sounds plausible, I can post an RFC series of the
subsystem within a week, together with a link to a git repository
with pon-tool. Before that I want to move the OMCI transport to
generic netlink and validate it on a board.

	John


On 28.09.26 03:25, Andrew Lunn wrote:
> On Mon, Sep 28, 2026 at 07:11:19AM +0800, Gaoyang Wei wrote:
>> Hi Andrew,
>>
>>> Another question which might affect the architecture. From what you
>>> have described, an ONU might be assigned multiple Port-IDs so it can
>>> carry multiple, separated, service traffic streams? You would want to
>>> represent each stream as a Linux netdev, with its own IP addresses
>>> etc.
>>
>> An ONU can indeed have multiple GEM Port-IDs, but I think there is one
>> important distinction here: a GEM Port-ID is not necessarily equivalent
>> to one Linux service interface.
>>
>> G.988 has an interworking layer between the GEM connections and the
>> Ethernet-facing service.
>>
>> For example, one Ethernet UNI can use an IEEE 802.1p mapper which sends
>> different priority classes to different GEM ports.  Bridge and VLAN
>> configuration can also make the relationship between Ethernet services
>> and GEM connections non-1:1.
>>
>> Very roughly:
>>
>>                       Ethernet UNI
>>                            |
>>                    bridge / mapper /
>>                      VLAN handling
>>                      /     |     \
>>                     /      |      \
>>               GEM port  GEM port  GEM port
>>                  100       101       102
> 
> I think that is too roughly, because that is not how Linux actually
> works.
> 
> A normal setup would be
> 
>                  br0
>                   | 
> 		Bridge
> 		|    |
>                eth0 eth1
> 
> and
> 
> 	vlan0:42
> 	 |
> 	 eth0
> 
> What it sounds like it should be is
> 
> 
>                  br0
>                   | 
> 		Bridge
> 		|    |
>                eth0 eth1
>                 |    
>        ------mapper------
>       /        |         \ 
>     GEM port  GEM port  GEM port
>        100       101       102
> 
> You get your 802.1p tagged frames flowing down from user space and at
> the bottom you map them to GEM ports.
> 
> How you classify frames above to tag them for 802.1p should be out of
> scope at this level, it is a TC problem, or done via the VLAN
> interfaces stacked on top of the base interface. It is a solved
> problem Linux can already do. It is the mapper which is new.
> 
> But i assume this is also possible:
> 
> 
>                eth0                                 eth1		
>                 |    		                     |    		
>        ------mapper------	            ------mapper------		
>       /        |         \ 	           /        |         \ 	
>     GEM port  GEM port  GEM port         GEM port  GEM port  GEM port
>        100       101       102              103       104       105  
> 
> 
>> Putting your two suggestions together seems to lead to a cleaner model:
>>
>>                      +------------------+
>>                      |    PON device    |
>>                      |  (wiphy-like)    |
>>                      +--------+---------+
>>                               |
>>                 +-------------+-------------+
>>                 |                           |
>>              AF_OMCI                 service interfaces
>>                 |                           |
>>           OMCI userspace             Linux net_device(s)
>>                                             |
>>                                    VLAN / TC / bridge
>>                                             |
>>                                       GEM mapping
> 
> You might want to talk to the wifi developers. Do they actually like
> the wiphy model, does it work for them, or do they wish they could
> throw it away and start again? What would they do differently?
> 
>> That also seems to answer part of the question raised by your AF_OMCI
>> idea.
>>
>> If OMCI is a protocol associated with this lower-level PON object,
>> then there is no need for a synthetic omci0 merely to obtain
>> AF_PACKET semantics.
> 
> So as you say, one question is, how do you associate an AF_OMCI socket
> to the lower level PON object? A typically home router probably has a
> single SFP cage, but maybe somebody will build a box with two SFP
> cages, you can connect to two independent providers so you have
> redundancy, and load balancing, etc.
> 
> How does addressing work at this level? BSD Sockets can use bind(1) to
> set the local address. Or you have SO_BINDTODEVICE socket option, if
> there is a name which can be used. I don't think it needs an ifindex.
> 
> 	Andrew
> 
>