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

[Matheus Sampaio Queiroga <srherobrine20@gmail.com>]

>  > I exposed it by poling in ioctl in the dirtiest way possible, by
>  > generic netlink and for sysfs.
> 
> This sounds different from the packet-oriented net_device design I was
> asking about.
> 
> My earlier question was specifically about the OMCI interface which
> users were able to attach to a bridge: was that interface registered
> as ARPHRD_ETHER?
> 
> If so, I think the bridge problem is probably orthogonal to whether
> OMCI is represented by a net_device.  An ARPHRD_NONE OMCI device with
> no Ethernet header should not be bridgeable in the first place.

sdk userspace use normal netdev with this flags: NETIF_F_NO_CSUM (for old qmda versions en751221, en7528), IFF_NOARP, IFF_BROADCAST and clear IFF_MULTICAST

>  > with a similar port of the Airoha SDK I had CPU usage of around
>  > 2~15% ...
>  >
>  > With OMCI in the kernel, the CPU overhead dropped to around
>  > 0.8~2.0% ...
> 
> Could you describe how these numbers were measured?
> 
> In particular, it would be useful to know:
> 
>    - which SoC and CPU frequency were used;
>    - whether the userspace version used polling, Generic Netlink, or a
>      packet socket in the measured configuration;
>    - what the MIB size / message rate was;
>    - whether the memory numbers are process RSS, total system memory,
>      or kernel allocations;
>    - whether both implementations used the same MIB representation.
> 
> I ask because a polling ioctl/sysfs implementation would have very
> different overhead from an AF_PACKET-based OMCI transport, so I do not
> think we can yet attribute the measured difference to the
> kernel/userspace boundary itself.
> 
> The Realtek case you described is also useful.  If the OMCI payload is
> the same and only the data source and hardware delivery path differ,
> that sounds like a good candidate for a small transport/backend
> abstraction rather than putting those vendor differences into the
> generic OMCI model.
> 
> On the optical side, your explanation also helps.  Keeping telemetry
> in hwmon, calibration in NVMEM, and leaving wavelength/frequency
> selection to the PHY where the PHY already owns it sounds like a
> reasonable boundary to me.

all tests were monitoring the IRQs and threads through top and htop on SoCs of the en7523 family (en7529ct and en7529dt) with a frequency of 1Ghz and 1.2Ghz on 2CPU cores, with 256Mb and 512Mb of ram, in total 3 tests were carried out for both implementations,
with 350, 600 and 800 MIB objects in both userspace and kernel space.

The tests monitored the total use of the system with only the xPON subsystem and the basic one for a DHCP and wireless server for 15 minutes

polling tests crashed the system several times and were not fully tested

the entire system before the xpon subsystem was started was using between 60mb~80mb of ram with both userspace and kernel space