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

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Matheus,

Thanks, the measurements are useful.

I think there are two details I would like to clarify before drawing
conclusions from them.

 > 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.

 > 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.

Thanks,
Gaoyang