On 05. 09. 25 1:14 odp., Kubalewski, Arkadiusz wrote:
From: Jakub Kicinski <[email protected]>
Sent: Saturday, August 30, 2025 2:34 AM
On Fri, 29 Aug 2025 07:49:46 +0000 Kubalewski, Arkadiusz wrote:
From: Jakub Kicinski <[email protected]>
Sent: Friday, August 29, 2025 12:32 AM
On Thu, 28 Aug 2025 18:43:45 +0200 Arkadiusz Kubalewski wrote:
Add support for user-space control over network device transmit clock
sources through a new extended netdevice netlink interface.
A network device may support multiple TX clock sources (OCXO, SyncE
reference, external reference clocks) which are critical for
time-sensitive networking applications and synchronization protocols.
how does this relate to the dpll pin in rtnetlink then?
In general it doesn't directly. However we could see indirect relation
due to possible DPLL existence in the equation.
The rtnetlink pin was related to feeding the dpll with the signal,
here is the other way around, by feeding the phy TX of given interface
with user selected clock source signal.
Previously if our E810 EEC products with DPLL, all the ports had their
phy TX fed with the clock signal generated by DPLL.
For E830 the user is able to select if the signal is provided from: the
EEC DPLL(SyncE), provided externally(ext_ref), or OCXO.
I assume your suggestion to extend rtnetlink instead of netdev-netlink?
Yes, for sure, but also I'm a little worried about this new API
duplicating the DPLL, just being more "shallow".
What is the "synce" option for example? If I set the Tx clock to SyncE
something is feeding it from another port, presumably selected by FW or
some other tooling?
In this particular case the "synce" source could point to a DPLL device of EEC
type, and there is a sense to have it together in one API. Like a two pins
registered with a netdev, one is input and it would be used for clock recovery,
second is output - for tx-clk control - either using the DPLL device produced
signal or not. Probably worth to mention this is the case with 'external' DPLL,
where ice driver doesn't control a DPLL device but it could use the output as
is this 'synce' one doing.
Yes, this simply describes a diagram I described in my DT RFC [1] that
defines relationship between DPLL device and network card.
+-----------+
+--| NIC 1 |<-+
| +-----------+ |
| |
| RxCLK TxCLK |
| |
| +-----------+ |
+->| channel 1 |--+
+------+ |-- DPLL ---|
| GNSS |---------->| channel 2 |--+
+------+ RefCLK +-----------+ |
|
TxCLK |
|
+-----------+ |
| NIC 2 |<-+
+-----------+
Here we have 2 scenarios... The first (NIC1) is a SyncE one where NIC1
feeds some DPLL input reference with recovered clock and consumes the
synchronized signal from the DPLL output pin as Tx clock. In the second
(NIC2) case the NIC uses some DPLL output pin signal as Tx clock and
the DPLL is synchronized with some external source.
If I understand well your comment, the RxCLK above is the dpll_pin
currently present in net_device. The TxCLK for the first case (NIC1)
should be the dpll_pin you are calling as "synce" source. And TxCLK for
the second case (NIC2) should be the dpll_pin you are calling "ext-ref".
Is it correct?
If so there should be another dpll_pin in the net_device let's call it
tx_dpll_pin... The existing one should be some input pin of some DPLL
device and the tx_dpll_pin should be some output pin of that device.
A user could set the tx_dpll_pin by ip link command like:
# ip link set eth0 txclk <dpll-pin-id>
[1]
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
Similar on ext-ref, there has to be a DPLL somewhere in the path,
in case reference goes away? We assume user knows what "ext-ref" means,
it's not connected to any info within Linux, DPLL or PTP.
Adding control over 'ext-ref' muds up the clean story of above.. The 'ext-ref'
source is rather an external pin, which have to be provided with external
clock signal, not defined anywhere else, or connected directly to DPLL device.
Purely HW/platform dependent. User needs to know the HW connections, the
signal to this pin could be produced with external signal generator, same host
but a different DPLL device, or simply different host and device. There can be
a PLL somewhere between generator and TX PHY but there is no lock status, thus
adding new dpll device just to model this seemed an overshot.
Exactly because of nature of 'ext-ref' decided to go with extending the
net device itself and made it separated from DPLL subsystem.
Please share your thoughts, right now I see two ways forward:
- moving netdev netlink to rt-netlink,
- kind of hacking into dpll subsystem with 'ext-ref' and output netdev pin.
You are mentioning above the case where an external DPLL device that is
not under control of network driver (e.g. DPLL chip on motherboard and
some LOM NIC). In this case is currently impossible for the NIC driver
to report dpll_pin used for recovered clock as it does not control the
DPLL device and all dpll_devices and dpll_pins are registered by the
different driver.
There could be defined some DT schema for the relations between ethernet
controller and used DPLL device. Then the system firmware (DT/ACPI...)
could provide the wiring info (e.g. DPLL pin REF0P is used for recovered
clock from NIC1 and output pin OUT4P for the Tx clock by NIC1 etc.)
...and also there should be some DPLL API for the drivers that would
allow to access DPLL devices and pins. E.g. NIC driver reads from its
fwnode that possible tx-clock pins could be out_pin1, 3, 5 but it needs
to translate fwnode_handles of these pins to registered DPLL pin IDs.
Thanks,
Ivan
