Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Machnikowski, Maciej" <maciej.machnikowski@intel.com>
To:     Richard Cochran <richardcochran@gmail.com>
CC:     "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "shuah@kernel.org" <shuah@kernel.org>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "nikolay@nvidia.com" <nikolay@nvidia.com>,
        "cong.wang@bytedance.com" <cong.wang@bytedance.com>,
        "colin.king@canonical.com" <colin.king@canonical.com>,
        "gustavoars@kernel.org" <gustavoars@kernel.org>,
        "Bross, Kevin" <kevin.bross@intel.com>,
        "Stanton, Kevin B" <kevin.b.stanton@intel.com>,
        Ahmad Byagowi <abyagowi@fb.com>
Subject: RE: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state
Thread-Topic: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state
Thread-Index: AQHXkrpDE4/97678+kqD5jc+QEB2qKt2zoSAgACcQzCAAhWPgIAAVWdwgAEkIgCAAAB9kIABl9IAgAAdxFA=
Date:   Fri, 20 Aug 2021 18:30:02 +0000
Message-ID: <PH0PR11MB49518ED9AAF8B543FD8324B9EAC19@PH0PR11MB4951.namprd11.prod.outlook.com>
References: <20210816160717.31285-1-arkadiusz.kubalewski@intel.com>
 <20210816160717.31285-2-arkadiusz.kubalewski@intel.com>
 <20210816235400.GA24680@hoboy.vegasvil.org>
 <PH0PR11MB4951762ECB04D90D634E905DEAFE9@PH0PR11MB4951.namprd11.prod.outlook.com>
 <20210818170259.GD9992@hoboy.vegasvil.org>
 <PH0PR11MB495162EC9116F197D79589F5EAFF9@PH0PR11MB4951.namprd11.prod.outlook.com>
 <20210819153414.GC26242@hoboy.vegasvil.org>
 <PH0PR11MB4951F51CBA231DFD65806CDAEAC09@PH0PR11MB4951.namprd11.prod.outlook.com>
 <20210820155538.GB9604@hoboy.vegasvil.org>
In-Reply-To: <20210820155538.GB9604@hoboy.vegasvil.org>
Accept-Language: en-US
Content-Language: en-US
dlp-reaction: no-action
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?naps1HmLR9fCk5r1hb4Gtq8UORJ1LDBZ9L19fnXqa4xVOd080jiEMcGTW54/?=
 =?us-ascii?Q?6bgwjz+vO1ePANB3nNAYtGGqw2nzrpe/8x01kRpuim1NaF8T9m7EqLIr8VMI?=
 =?us-ascii?Q?UM2hOiZGBnFVrTLUJlwnHcTAVTVcaMW/XLdSF4hxV9PV16FZaycfAn35A/eS?=
 =?us-ascii?Q?wtZzj7IuAZNYNzmxgsxc3DnA4mNGCvlJFBcOVCXeFuXcPULYNh+OekMJLykg?=
 =?us-ascii?Q?jihJoO+OvGQ25E+BU3M756acAG0wZTQzsBYGoe1YJ/oP+Jyq0cubSJsPL10/?=
 =?us-ascii?Q?DXZkfitVf9l0wSJ9N4snJp+Hbp3aboaIz1AIGdAgDjf6b6EJH1YFWgbxHjP+?=
 =?us-ascii?Q?UbptnncLB+mk1PUgnStAa7d1dfiw31VGOff0OW77kvrEzlEDQeDpHL999sV/?=
 =?us-ascii?Q?u0HdSTZkQ+YzYiWnF4iwozqniV9eM+yC2a8j91P1NI4v3PRJJj5gteY0aR24?=
 =?us-ascii?Q?62ZdZyE3tJ/Azw2jQwKWEvnkGKoeqvSyey6r5SLYAVzhgN98ZTj1A8PZmkHk?=
 =?us-ascii?Q?MIXKk9fW+CCeDzlUqmev2TZ27IXk5mWuMXGOBjA+ggVnAFLR1ByCaSriUuIM?=
 =?us-ascii?Q?7t9j8f/Wj0aM+pjMkd8iyaqKTs9erNKgePxRcIXNsXB69iBfE34UC5smztXi?=
 =?us-ascii?Q?QY2ZNDnD6Q1UGDptQXnvleii70UNp9SW3H59nM4SIw68edgzGFrB9GyfYWKG?=
 =?us-ascii?Q?BXi8B9hEv1Hi6fxfDfxJMcw3LhhUvLGMXBBCOF0ph0UrMS++/sx0hmh3ODDc?=
 =?us-ascii?Q?nYY0jEn3fLc4KU7RsYUna26by7h5XXIVjvwYHx1kg8ZbppQ6QXx3YGS/ecun?=
 =?us-ascii?Q?nBdUAhTYgAiHxE0E7Cp0OCG9PZdoiNXkFE77owPLYe5iJIHdsSdom+OxQfvx?=
 =?us-ascii?Q?9wlAaoOWOR2sFJq1vcIdH9yfhFHbuiVy2bW1kTxM0766zzOwMH9Gq+RQVoWd?=
 =?us-ascii?Q?1+vtHKfoP+lLSDnxs2rg0skhyr5ZkR37HJRA2sM+URQLnbPznJPWLPzCMBty?=
 =?us-ascii?Q?X7rFd1JvASiPpR68SrUOzAFFj2V4iGoeMcmcKR+YgvUIcNYMDIZEq62ydWpo?=
 =?us-ascii?Q?ygOlaVIbWBEEi+g9CXmwk0Qwz9UpWVPat5yOnVqWz4KnctTu1/UD+SP90JKF?=
 =?us-ascii?Q?WSfESH3rXktDStoo2dd+ZdunF2puNi0JFykrAtx2BG7UArnHLyq92WOISQAS?=
 =?us-ascii?Q?3a0AVKzS85oOsbafWHqEpaPvakthFHw+w+B8A+xVEtT9GXgQhZs/XabRwhpo?=
 =?us-ascii?Q?Eq6O5O9C4cwVhKsLjf1HELEJtIsB+D+g6Q1rhD3UiFnNUjgcMMZX/SZL2xHR?=
 =?us-ascii?Q?jVk=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4951.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc869b13-35a9-472f-7376-08d964088694
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2021 18:30:02.8942
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /nIuuhvvim9Abs+HULaGgxicVI0HZ9hjDpfjtDN2BuZejilLaItq1xtEAmPfW5QTrfAgcBdJy1LEPaGh7KB2aNeaAW7OvWSKH2zSDBox93U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5189
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Richard Cochran <richardcochran@gmail.com>
> Sent: Friday, August 20, 2021 5:56 PM
> To: Machnikowski, Maciej <maciej.machnikowski@intel.com>
> Cc: Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; linux-
> kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kselftest@vger.kernel.org; Brandeburg,
> Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net; kuba@kernel.org;
> shuah@kernel.org; arnd@arndb.de; nikolay@nvidia.com;
> cong.wang@bytedance.com; colin.king@canonical.com;
> gustavoars@kernel.org; Bross, Kevin <kevin.bross@intel.com>; Stanton,
> Kevin B <kevin.b.stanton@intel.com>; Ahmad Byagowi <abyagowi@fb.com>
> Subject: Re: [RFC net-next 1/7] ptp: Add interface for acquiring DPLL sta=
te
>=20
> 1. Control bits according to IEEE 802.3 Section 40.5.2 as Ethtool or RTNL=
.
>=20
> 2. User space Ethernet Synchronization Messaging Channel (ESMC)
>    service according to IEEE 802.3ay
>=20
> The PHY should be automatically controlled by #1.
>=20
> As I said before, none of this belongs in the PHC subsystem.
>=20
> Thanks,
> Richard

Sure!

I did a talk at netDev 0x15 covering SyncE - you can refer to the slides fo=
r more detailed info, and hopefully the recording will be available soon as=
 well:
https://netdevconf.info/0x15/session.html?Introduction-to-time-synchronizat=
ion-over-Ethernet

At its core - SyncE requires 2 parts (see slide 22/23)
 - SyncE capable PHY
 - the external DPLL

The SyncE capable PHY is a PHY that can recover the physical clock, at whic=
h the data symbols are transferred, (usually) divide it and output it to th=
e external PLL. It can also redirect the recovered and divided clock to mor=
e than one pin.
Since the 40.5.2 is not applicable to higher-speed ethernet which don't use=
 auto-negotiation, but rather the link training sequence where the RX side =
always syncs its clock to the TX side.

The external DPLL tunes the frequency generated by a crystal to the frequen=
cy recovered by the PHY, and drives the outputs.

On the other end - the SyncE PHY uses the clock generated by the DPLL to tr=
ansmit the data to the next element.

So to be able to control SyncE we need 2 interfaces:
- Interface to enable the recovered clock output at the given pin
- interface to monitor the DPLL to see if the clock that we got is valid, o=
r not.

If it comes to ESMC (G.8264) messages, SyncE itself can run in 2 modes (sli=
des 29/30 will give you more details):
- QL-Disabled - with no ESMC messages - it base on the local information fr=
om the PLL to make all decisions
- QL-Enabled - that adds ESMC and quality message transfer between the node=
s.

Additionally, the SyncE DPLL can be synchronized to the external sources, l=
ike a 1PPS or a 10M signal from the GNSS.

That's why the RFC proposes 2 interfaces:
- one for enabling redirected clock on a selected pin of the PHY
- one for the physical frequency lock of the DPLL

The connection with the PTP subsystem is that in most use cases I heard abo=
ut SyncE is used as a physical frequency syntonization for PTP clocks.
Hence adding a DPLL monitoring there would solve 2 issues at the same time =
- monitoring of a GNSS-syntonized PTP clock and the SyncE syntonized one an=
d would make a single point to monitor by the upper layer applications.

Let me know if that makes more sense now. We could add a separate SyncE and=
 separate PTP DPLL monitoring interfaces, but in most cases they will point=
 to the same device.

Regards
Maciek