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

[Andrew Lunn <andrew@lunn.ch>]

> ITU-T G.984.3 defines it roughly as:
> 
>      bit
>        0          11 12         23 24  26 27          39
>        +-------------+-------------+------+--------------+
>        |   PLI (12)  | Port-ID (12)| PTI  |   HEC (13)   |
>        +-------------+-------------+------+--------------+
>        |<---------------- 5 octets --------------------->|
> 
>        PLI       Payload Length Indicator
>        Port-ID   GEM logical connection identifier
>        PTI       Payload Type Indicator
>        HEC       Header Error Control
> 
> and the frame is:
> 
>        +-----------------------+--------------------------+
>        | GEM header, 5 octets  |       GEM payload       |
>        +-----------------------+--------------------------+
> 


> The field relevant here is the Port-ID.
> > How can you tell apart a OMCI PDU from a user data PDU?
> 
> That distinction is normally made using the GEM/XGEM Port-ID before the OMCI
> implementation sees the packet.


> Depending on the hardware, some information from the PON side may still be
> available after de-encapsulation.

So in general, the hardware is doing some level of demux?

I would of put everything as it is into the skbuf, and pass it to the
network stack, telling it what the first header is. It can then look
into the header and demux it, same as it does for any other protocol
the Linux stack handles. You can also hand this off via pcap for
tcpdump/wireshark.

If the hardware is doing the demux, try to feed the skbuf in one level
higher in the stack?

> If the immediate userspace requirement is simply transporting
> already-demultiplexed OMCI PDUs, AF_PACKET already provides a packet
> transport abstraction.

Throwing out another idea, which maybe completely wrong...

An interface is just a device which receives frames from the media. It
can have multiple protocols running on top of that interface:

6: eth42: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.20.0.82 peer 10.20.0.1/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::61ae:d150:2724:7d6f/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever

Here there is AF_INT and AF_INT6 address families on top of the
interface.

Would it make sense to add an AF_OMCI?

> So the part I am still trying to understand is whether a minimal
> non-Ethernet net_device, used only as an AF_PACKET endpoint for these
> already-decapsulated OMCI PDUs, would itself be considered the wrong
> abstraction.

An interface which is not an interface causes a lot of confusion. The
DSA model for switches has shown that. You really want to avoid this.

    Andrew