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 4EB7FCCA47F for ; Tue, 7 Jun 2022 09:14:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239046AbiFGJOU (ORCPT ); Tue, 7 Jun 2022 05:14:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238703AbiFGJOS (ORCPT ); Tue, 7 Jun 2022 05:14:18 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FA7169B53; Tue, 7 Jun 2022 02:14:14 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1654593252; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bezUUwZTcrVCpPMRY2+6dN6//+KpHkGmqvWXkpIPhNU=; b=Cs/VMGvhIXHBotoccSXQdMLGz/D+jPs57h++NHgNdhmYEW5ts7QKRrtItm+qSQz+1X29dv Qrlo+ZmRSRLr9CU7iE25N049w0EYdxZQv24CY3e1r7H5Oiu9mA8fIqesjduNkOQoSoV4yA u/bPmRhcIB5kPNv7OO7KEd/tdjnpZJgQlGmHozAgNAzgy3DB60UzcuBQtLk4ftjYGfR6V2 2EyMe1cKjfSVutlWvew8MLSk1v8Fre+4zON1lu25mneaSvS03xdM5nKOB5wdoAPaL0j2ht 7fSUIR9suTfbm716bIvxDxfqCF6POnOmH+PYXblSQncHX6BS5RxSphUgkvfJ+w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1654593252; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bezUUwZTcrVCpPMRY2+6dN6//+KpHkGmqvWXkpIPhNU=; b=pYAGvdTIZ9X8TbLxsUdPagFnvFAgjv9BIuXSUxHX8dsmfPgKYxwyv3gbwc9/MQhnwzVx1N iKb8Pc20Uyf1/NDA== To: Alexei Starovoitov , Kurt Kanzenbach Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Joanne Koong , Jiri Olsa , Dave Marchevsky , Lorenzo Bianconi , Geliang Tang , Jakub Sitnicki , Network Development , bpf , Jesper Dangaard Brouer Subject: Re: [PATCH bpf-next] bpf: Add BPF-helper for accessing CLOCK_TAI In-Reply-To: References: <20220606103734.92423-1-kurt@linutronix.de> Date: Tue, 07 Jun 2022 11:14:12 +0200 Message-ID: <875ylc6djv.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Alexei, On Mon, Jun 06 2022 at 08:57, Alexei Starovoitov wrote: > On Mon, Jun 6, 2022 at 3:38 AM Kurt Kanzenbach wrote: >> >> From: Jesper Dangaard Brouer >> >> Commit 3dc6ffae2da2 ("timekeeping: Introduce fast accessor to clock tai") >> introduced a fast and NMI-safe accessor for CLOCK_TAI. Especially in time >> sensitive networks (TSN), where all nodes are synchronized by Precision Time >> Protocol (PTP), it's helpful to have the possibility to generate timestamps >> based on CLOCK_TAI instead of CLOCK_MONOTONIC. With a BPF helper for TAI in >> place, it becomes very convenient to correlate activity across different >> machines in the network. > > That's a fresh feature. It feels risky to bake it into uapi already. What? That's just support for a different CLOCK. What's so risky about it? > imo it would be better to annotate tk_core variable in vmlinux BTF. > Then progs will be able to read all possible timekeeper offsets. We are exposing APIs. APIs can be supported, but exposing implementation details creates ABIs of the worst sort because that prevents the kernel from changing the implementation. We've seen the fallout with the recent tracepoint changes already. Thanks, tglx