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

[Andrew Lunn <andrew@lunn.ch>]

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