From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D95D1C433EF for ; Wed, 8 Sep 2021 23:58:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B5B58610A3 for ; Wed, 8 Sep 2021 23:58:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244155AbhIHX7N (ORCPT ); Wed, 8 Sep 2021 19:59:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:59522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234374AbhIHX7M (ORCPT ); Wed, 8 Sep 2021 19:59:12 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 637B661074; Wed, 8 Sep 2021 23:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631145483; bh=naqFHkyuBJj75mYvsBiHe8qSClYBBKiI1/BuxmIm9Rc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JZjlze49Z84VDPYYfXqYdWFDEUisnWjMKAHNR4JLCOM9bKq90K7M4MqpqsRhnH+Nd WAIF4JFhDWbdo72pXx89d/i3xRFdssgDzTjrTQCQw7eh6tTOSDz8CLtn9XdO1BKqkg s7F1OorDuTZZhsgS4doHJ2tab8EElZGmRh12bRXUqywjXAL4hhLCDn8gcjXoOw1S+C 3pGCaNmxtOoylC5oNIKVeERm20Bs+SZzoBAogKqI6U0zzeimh0+jbedBxy6FMcoZTF 5VIPFOLq3DMzEmZ6ZMdS9JtdUJLM6hrYxT7J875+3aRqntafz5qdmqqp8UPCSHW1II 5mile4vYJlcJA== Date: Wed, 8 Sep 2021 16:58:02 -0700 From: Jakub Kicinski To: Andrew Lunn Cc: "Machnikowski, Maciej" , "netdev@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "richardcochran@gmail.com" , "abyagowi@fb.com" , "Nguyen, Anthony L" , "davem@davemloft.net" , "linux-kselftest@vger.kernel.org" , Michal Kubecek , Saeed Mahameed , Michael Chan Subject: Re: [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Message-ID: <20210908165802.1d5c952d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20210906180124.33ff49ef@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210907075509.0b3cb353@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210907124730.33852895@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908092115.191fdc28@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908151852.7ad8a0f1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 9 Sep 2021 01:14:36 +0200 Andrew Lunn wrote: > > As you said, pin -> ref mapping is board specific, so the API should > > not assume knowledge of routing between Port and ECC. > > That information will probably end up in device tree. And X different > implementations of ACPI, unless somebody puts there foot down and > stops the snow flakes. > > > Imagine a system with two cascaded switch ASICs and a bunch of PHYs. > > How do you express that by pure extensions to the proposed API? > > Device tree is good at that. ACPI might eventually catch up. I could well be wrong but some of those connectors could well be just SMAs on the back plate, no? User could cable those up to their heart content. https://engineering.fb.com/2021/08/11/open-source/time-appliance/ > How complex a setup do we actually expect? Can there be multiple > disjoint SyncE trees within an Ethernet switch cluster? Or would it be > reasonable to say all you need to configure is the clock source, and > all other ports of the switches are slaves if SyncE is enabled for the > port? I've never see any SOHO switch hardware which allows you to have > disjoint PTP trees, so it does not sound too unreasonable to only > allow a single SyncE tree per switch cluster. Not sure. I get the (perhaps unfounded) feeling that just forwarding the clock from one port to the rest is simpler. Maciej cares primarily about exposing the clock to other non-Ethernet things, the device would be an endpoint here, using the clock for LTE or whatnot. > Also, if you are cascading switches, you generally don't put PHYs in > the middle, you just connect the SERDES lanes together. My concern was a case where PHY connected to one switch exposes the refclock on an aux pin which is then muxed to more than one switch ASIC. IOW the "source port" is not actually under the same switch. Again, IDK if that's realistic. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Date: Wed, 8 Sep 2021 16:58:02 -0700 Subject: [Intel-wired-lan] [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status In-Reply-To: References: <20210906180124.33ff49ef@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210907075509.0b3cb353@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210907124730.33852895@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908092115.191fdc28@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908151852.7ad8a0f1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Message-ID: <20210908165802.1d5c952d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Thu, 9 Sep 2021 01:14:36 +0200 Andrew Lunn wrote: > > As you said, pin -> ref mapping is board specific, so the API should > > not assume knowledge of routing between Port and ECC. > > That information will probably end up in device tree. And X different > implementations of ACPI, unless somebody puts there foot down and > stops the snow flakes. > > > Imagine a system with two cascaded switch ASICs and a bunch of PHYs. > > How do you express that by pure extensions to the proposed API? > > Device tree is good at that. ACPI might eventually catch up. I could well be wrong but some of those connectors could well be just SMAs on the back plate, no? User could cable those up to their heart content. https://engineering.fb.com/2021/08/11/open-source/time-appliance/ > How complex a setup do we actually expect? Can there be multiple > disjoint SyncE trees within an Ethernet switch cluster? Or would it be > reasonable to say all you need to configure is the clock source, and > all other ports of the switches are slaves if SyncE is enabled for the > port? I've never see any SOHO switch hardware which allows you to have > disjoint PTP trees, so it does not sound too unreasonable to only > allow a single SyncE tree per switch cluster. Not sure. I get the (perhaps unfounded) feeling that just forwarding the clock from one port to the rest is simpler. Maciej cares primarily about exposing the clock to other non-Ethernet things, the device would be an endpoint here, using the clock for LTE or whatnot. > Also, if you are cascading switches, you generally don't put PHYs in > the middle, you just connect the SERDES lanes together. My concern was a case where PHY connected to one switch exposes the refclock on an aux pin which is then muxed to more than one switch ASIC. IOW the "source port" is not actually under the same switch. Again, IDK if that's realistic.