Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2778007iog; Mon, 27 Jun 2022 02:43:13 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vARY9pQ2zXRTH0sqpNRQBESgvQr2C9jzfBG0tpzwtRGA0nl6nFmZPfXQRt8twpH3m4sxnb X-Received: by 2002:a17:906:3985:b0:70c:a5fe:d4fb with SMTP id h5-20020a170906398500b0070ca5fed4fbmr11478728eje.127.1656322993382; Mon, 27 Jun 2022 02:43:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656322993; cv=none; d=google.com; s=arc-20160816; b=Pv3Ma3l+rooo+XzZ3SYvnu7bAmi2LoeORwSdp9mGoJcuNvuUDmr8TH3FImb5j4iCW7 KqXELDYC2VwMI+LKTfr8t2DeZtodAJwjFYqLpt1LGaTUh9KNQ0+K4Y33v3KaIRiZPnWo Y/ABCfxAdwNLPJxl86EldbNLb2FkU0t4temYAMlk5xhELTk3P1P986YsPTXkOeHCoqDA AvvMVwfMhitHuU/QScend81P0k50u69VRyrza8AdKYRJ1B3L8pIaI3l8c2H8s8R59i8x MIRPaaN4iTQiOrjENDclymm8d5iU3m+LM0x8347oUMp9TxKPGgDa/z7qu+6QvGt3eIz/ nr2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=xq1pGT9lGoi0nSCi93R5HPmRt/mgxDOHNhfwN7bnmxE=; b=q4HHr9qnm3IMHyFiPt7912tjWtuFXw4eUlOgUeFv4689qR1it35lYXbWSAE1iqXgHG cCu2FbdwJulNBhcEVQK48goguaZyHBA5mqq5ayxgV4epJFYSfRmA69w07jcAKY3CdqEC a0xxeCj1xiDkvNms4yE7T+4AlVAePvTqNGdBYqKffvteuHjycY/HiWZAwM9xnBym76T7 6el0K99M96lulpKG1E+Ezdw6eCUo/rmpkHa4M32XwDKc4j9uaivMR+V5POqpUW8stIWR ZzvzCjUKMOswnXI0NZitR496ugfHPqkScEGXnHKYKR7b/kEnz1hP+lqWzW0vh3Lsu/hR J+gg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ss28-20020a170907c01c00b00722e85dcd94si8771898ejc.375.2022.06.27.02.42.48; Mon, 27 Jun 2022 02:43:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233473AbiF0JZx (ORCPT + 99 others); Mon, 27 Jun 2022 05:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233023AbiF0JZx (ORCPT ); Mon, 27 Jun 2022 05:25:53 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0DD132DE4; Mon, 27 Jun 2022 02:25:52 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C4B141758; Mon, 27 Jun 2022 02:25:51 -0700 (PDT) Received: from [192.168.4.21] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9BC583F792; Mon, 27 Jun 2022 02:25:47 -0700 (PDT) Message-ID: <4e4b9e1a-778e-9ca1-5c15-65e45a532790@arm.com> Date: Mon, 27 Jun 2022 10:25:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH net-next 1/4] time64.h: define PSEC_PER_NSEC and use it in tc-taprio Content-Language: en-US To: Vladimir Oltean Cc: "netdev@vger.kernel.org" , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Xiaoliang Yang , Claudiu Manoil , Alexandre Belloni , "UNGLinuxDriver@microchip.com" , Andrew Lunn , Vivien Didelot , Florian Fainelli , Michael Walle , Vinicius Costa Gomes , Maxim Kochetkov , Colin Foster , Richie Pearn , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Thomas Gleixner References: <20220626120505.2369600-1-vladimir.oltean@nxp.com> <20220626120505.2369600-2-vladimir.oltean@nxp.com> <5db4e640-8165-d7bf-c6b6-192ea7edfafd@arm.com> <20220627085101.jw55y3fakqcw7zgi@skbuf> From: Vincenzo Frascino In-Reply-To: <20220627085101.jw55y3fakqcw7zgi@skbuf> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vladimir, On 6/27/22 09:51, Vladimir Oltean wrote: > Hi Vincenzo, > > On Mon, Jun 27, 2022 at 08:52:51AM +0100, Vincenzo Frascino wrote: >> Hi Vladimir, >> >> On 6/26/22 13:05, Vladimir Oltean wrote: >>> Time-sensitive networking code needs to work with PTP times expressed in >>> nanoseconds, and with packet transmission times expressed in >>> picoseconds, since those would be fractional at higher than gigabit >>> speed when expressed in nanoseconds. >>> >>> Convert the existing uses in tc-taprio to a PSEC_PER_NSEC macro. >>> >>> Cc: Andy Lutomirski >>> Cc: Thomas Gleixner >>> Cc: Vincenzo Frascino >>> Signed-off-by: Vladimir Oltean >>> --- >>> include/vdso/time64.h | 1 + >>> net/sched/sch_taprio.c | 4 ++-- >>> 2 files changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/vdso/time64.h b/include/vdso/time64.h >>> index b40cfa2aa33c..f1c2d02474ae 100644 >>> --- a/include/vdso/time64.h >>> +++ b/include/vdso/time64.h >>> @@ -6,6 +6,7 @@ >>> #define MSEC_PER_SEC 1000L >>> #define USEC_PER_MSEC 1000L >>> #define NSEC_PER_USEC 1000L >>> +#define PSEC_PER_NSEC 1000L >> >> Are you planning to use this definition in the vdso library code? If not, you >> should define PSEC_PER_NSEC in "include/linux/time64.h". The vdso namespace >> should contain only the definitions shared by the implementations of the kernel >> and of the vdso library. > > I am not. I thought it would be ok to preserve the locality of > definitions by placing this near the others of its kind, since a macro > doesn't affect the compiled vDSO code in any way. But if you prefer, I > can create a new mini-section in linux/time64.h. Any preference on where > exactly to place that definition within the file? I do not have a strong opinion on where to put it. But I think that if you put a section above TIME64_MAX should work. -- Regards, Vincenzo