RE: [PATCH v3 net-next 6/6] docs: net: Add description of SyncE interfaces

-----Original Message-----
From: Petr Machata <petrm@nvidia.com>
Sent: Tuesday, November 16, 2021 12:53 PM
To: Machnikowski, Maciej <redacted>
Subject: Re: [PATCH v3 net-next 6/6] docs: net: Add description of SyncE
interfaces


Machnikowski, Maciej [off-list ref] writes:

quoted

quoted

- Reporting pins through the netdevices that use them allows for
  configurations that are likely invalid, like disjoint "frequency
  bridges".

Not sure if I understand that comment. In target application a given
netdev will receive an ESMC message containing the quality of the
clock that it has on the receive side. The upper layer software will
see QL_PRC on one port and QL_EEC on other and will need to enable
clock output from the port that received QL_PRC, as it's the higher clock
class. Once the EEC reports Locked state all other ports that are traceable
to a given EEC (either using the DPLL subsystem, or the config file)
will start reporting QL_PRC to downstream devices.

I think I had the reading of the UAPI wrong. So RTM_SETRCLKSTATE means,
take the clock recovered from ifindex, and send it to pins that I have
marked with the ENA flag.

But that still does not work well for multi-port devices. I can set it
up to forward frequency from swp1 to swp2 and swp3, from swp4 to swp5
and swp6, etc. But in reality I only have one underlying DPLL and can't
support this. So yeah, obviously, I bounce it in the driver. It also
means that when I want to switch tracking from swp1 to swp2, I first
need to unset all the swp1 pins (64 messages or whaveter) and then set
it up at swp2 (64 more messages). As a user I still don't know which of
my ports share DPLL. It's just not a great interface for multi-port
devices.

This will only be done on init - after everything is configured - you will not
really need to check anything there.

Having this stuff at a dedicated DPLL object would make the issue go
away completely. A driver then instantiates one DPLL, sets it up with
RCLK pins and TX pins. The DPLL can be configured with which pin to take
the frequency from, and which subset of pins to forward it to. There are
as many DPLL objects as there are DPLL circuits in the system.

This works for simple port devices as well as switches, as well as
non-networked devices.

The in-driver LOC overhead is a couple of _init / _fini calls and an ops
structure that the DPLL subsystem uses to talk to the driver. Everything
else remains the same.

That won't work - a single recovered clock may be physically connected
to more than one DPLL device and a single DPLL device may be used for
more than one MAC chip at the same time - we shouldn't mix subsystems 
as recovered clocks belong to PHY/MAC layer.

Also in that case the DPLL would need to track the relation between
all netdev ports upstream - which will be nightmare to keep track of
when ports reset/get removed or added.

Also the netdev is the one that will receive the packet containing quality
so the userspace app will know which netdev received it and not which
DPLL pin it should configure. I think this approach will make everything
more complex (unless I'm missing something).

quoted

quoted

- It's not clear what enabling several pins means, and it's not clear
  whether this genericity is not going to be an issue in the future when
  we know what enabling more pins means.

It means that the recovered frequency will appear on 2 or more physical
pins of the package.

Yes, agreed now.