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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 34964C56201 for ; Wed, 25 Nov 2020 21:10:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E87EF2075A for ; Wed, 25 Nov 2020 21:10:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730974AbgKYVKA (ORCPT ); Wed, 25 Nov 2020 16:10:00 -0500 Received: from mailout07.rmx.de ([94.199.90.95]:47693 "EHLO mailout07.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729981AbgKYVJ7 (ORCPT ); Wed, 25 Nov 2020 16:09:59 -0500 Received: from kdin01.retarus.com (kdin01.dmz1.retloc [172.19.17.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout07.rmx.de (Postfix) with ESMTPS id 4ChD6q59sWzBvCq; Wed, 25 Nov 2020 22:09:55 +0100 (CET) Received: from mta.arri.de (unknown [217.111.95.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by kdin01.retarus.com (Postfix) with ESMTPS id 4ChD6Z68Y1z2xFb; Wed, 25 Nov 2020 22:09:42 +0100 (CET) Received: from n95hx1g2.localnet (192.168.54.19) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 25 Nov 2020 22:08:41 +0100 From: Christian Eggers To: CC: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for KSZ956x Date: Wed, 25 Nov 2020 22:08:39 +0100 Message-ID: <3569829.EPWo3g8d0Q@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: References: <20201118203013.5077-1-ceggers@arri.de> <2452899.Bt8PnbAPR0@n95hx1g2> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.19] X-RMX-ID: 20201125-220942-4ChD6Z68Y1z2xFb-0@kdin01 X-RMX-SOURCE: 217.111.95.66 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I need some help from Microchip, please read below. On Thursday, 19 November 2020, 19:51:15 CET, Tristram.Ha@microchip.com wrote: > There is one more requirement that is a little difficult to do. The calculated peer delay > needs to be programmed in hardware register, but the regular PTP stack has no way to > send that command. I think the driver has to do its own calculation by snooping on the > Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up messages. In an (offline) discussion with Vladimir we discovered, that the KSZ switch behaves different as ptp4l expects: The KSZ switch forwards PTP (e.g. SYNC) messages in hardware (with updating the correction field). For this, the peer delays need be configured for each port. ptp4l in turn expects to do the forwarding in software (for the P2P_TC clock configuration). For this, no hardware configuration of the peer delay is necessary. But due to limitations of currently available hardware, this TC forwarding is currently only supported for 2 step clocks, as a one-step clock would probably fully replace the originTimestamp field (similar as a BC, but not as a TC). Vladimir suggested to configure an ACL in the KSZ switch to block forwarding of PTP messages between the user ports and to run ptp4l as BC. My idea is to simply block forwarding of UDP messages with destination ports 319+320 and L2 messages with the PTP Ether-Type. I installed the following ACL (for UDP) in the Port ACL Access registers 0-F: |_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F | 00 39 01 40 01 3F 42 22 00 00 00 60 00 00 00 01 ACL index: 0 Match: - MD=11 (L4) - ENB=10 (UDP ports) - S/D=0 (dst) - EQ=1 (equal) - MAX_PORT=320 - MIN_PORT=319 - PC=01 (min or max) - PRO=17 (UDP, don't care?) - FME=0 (disabled) Action: - PM=0 (disabled) - P=0 (don't care) - RPE=0 (disabled) - RP=0 (don't care) - MM=11 (replace) - PORT_FWD_MAP: all ports to 0 Processing entry: - Ruleset=0x0001 - FRN=0 Unfortunately, with this configuration PTP messages are still forwarded from port 1 to port 2. Although I was successful in blocking other communication (e.g. by MAC address), the matching rules above seem not to work. Is there an error in the ACL, or is forwarding of PTP traffic independent of configured ACLs? regards Christian