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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 876AEC2BB3F for ; Mon, 20 Nov 2023 21:46:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232340AbjKTVqG (ORCPT ); Mon, 20 Nov 2023 16:46:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232359AbjKTVp5 (ORCPT ); Mon, 20 Nov 2023 16:45:57 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D239A4 for ; Mon, 20 Nov 2023 13:45:54 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7FB0C433C8; Mon, 20 Nov 2023 21:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700516753; bh=wTllnXLudtUSjHaEEAUK+L8ZBRUeteK9UhJ3dFHB6P8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Xhk8t6N3NQbIK326t8vzbsC+Lh1F7QrLoyQS5Ngt/uCzxNxN1JnMsa3RF5AMjo7xP 1pKL4LaoF4ivTbBnK5MnMyKKLk03xf7wmnEKFUD8DGnnFmxJn1eZeW27On+/qwCKtQ zX6ux2sLm96LaMruFuqUAX1Jy99M6InH4ZT1n3ddfUCWg6mjZvUXxPHxe1iB9k/7aS Ttp3zViQ4WOpzAmGOkaZ1mKvrVk9rIFuOjdZ5acoNbUBA3U4s1BPhBWt3/TrgIPCSn NOWtkHeoIjZkNPv/E3rDBr1ug2f/aounyeTdaO5Fb7z1WvjfhWhapi177br/EGlHEQ g8CzuXOpLfAEw== Date: Mon, 20 Nov 2023 13:45:51 -0800 From: Jakub Kicinski To: Vladimir Oltean Cc: Andrew Lunn , =?UTF-8?B?S8O2cnk=?= Maincent , Florian Fainelli , Broadcom internal kernel review list , Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Paolo Abeni , Richard Cochran , Radu Pirea , Jay Vosburgh , Andy Gospodarek , Nicolas Ferre , Claudiu Beznea , Willem de Bruijn , Jonathan Corbet , Horatiu Vultur , UNGLinuxDriver@microchip.com, Simon Horman , Thomas Petazzoni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Maxime Chevallier Subject: Re: [PATCH net-next v7 15/16] net: ethtool: ts: Let the active time stamping layer be selectable Message-ID: <20231120134551.30d0306c@kernel.org> In-Reply-To: <20231120195858.wpaymolv6ws4hntp@skbuf> References: <20231118183433.30ca1d1a@kernel.org> <20231120104439.15bfdd09@kmaincent-XPS-13-7390> <20231120105255.cgbart5amkg4efaz@skbuf> <20231120121440.3274d44c@kmaincent-XPS-13-7390> <20231120120601.ondrhbkqpnaozl2q@skbuf> <20231120144929.3375317e@kmaincent-XPS-13-7390> <20231120142316.d2emoaqeej2pg4s3@skbuf> <20231120093723.4d88fb2a@kernel.org> <157c68b0-687e-4333-9d59-fad3f5032345@lunn.ch> <20231120105148.064dc4bd@kernel.org> <20231120195858.wpaymolv6ws4hntp@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Nov 2023 21:58:58 +0200 Vladimir Oltean wrote: > I'm still waiting for you to fully clarify the "per socket vs global" > aspect, but independently of that, at least I understand why this is a > counter-argument to my proposal. I need to tune it a bit (ASSUMING that > we want DMA timestamps to "look like" hwtimestamps, and not like their > own thing, to user space), because the PHC index would no longer fully > identify a hwtstamp provider, so we need something more. > > I imagine both ETHTOOL_MSG_TSINFO_GET and ETHTOOL_MSG_TSINFO_SET to > support a new (nest) nlattr called ETHTOOL_A_TSINFO_HWSTAMP_PROVIDER. > > This would contain (u32) ETHTOOL_A_TSINFO_HWSTAMP_PROVIDER_PHC_INDEX > and (u32) ETHTOOL_A_TSINFO_HWSTAMP_PROVIDER_QUALIFIER. It could be > extensible in the future, but this is the baseline and forms the key. > > The latter takes values from an: > > enum ethtool_hwstamp_provider_qualifier { > ETHTOOL_HWSTAMP_PROVIDER_QUALIFIER_MAC, > ETHTOOL_HWSTAMP_PROVIDER_QUALIFIER_PHY, > ETHTOOL_HWSTAMP_PROVIDER_QUALIFIER_DMA, > }; Sounds reasonable. Having more attributes than just PHC index works. Given the lack of distinction between MAC and PHY for integrated NICs I'd lean towards ditching the "layers" completely and exposing an "approximate" vs "precise" boolean. Approximate being the DMA point for NICs, but more generically a point that is separated from the wire by buffering or other variable length delay. Precise == IEEE 1588 quality.