From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by mail.toke.dk (Postfix) with ESMTPS id D0069A4328B for ; Mon, 4 Dec 2023 15:58:49 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=REf5dVxN Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-77dd07e7d39so328102985a.0 for ; Mon, 04 Dec 2023 06:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701701868; x=1702306668; darn=xdp-project.net; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=4s/Fe1XG1yhJb8Cgkf39nJDFir7TwuGaTQXt4MseexI=; b=REf5dVxNavOmG9GaybXRJBWEDEefZdjnTkiXzeCX7TWAfHxxzP/5dlDgXpC297Lbv9 gJ4HKCqr5tpIek9UgJxpS6Ia/FlDdXR8MdDv1EMwrPosCp260gDprS5Nh6OC+GhZUDIo KfrfzLMrUStfiv9TlSr+EZXI6cSfYM9JHFX+Q5X4iYSqQlEH6GKaSgdCNoBXJh1YrAZ+ 0mR6yym5cMdrya16bbmbkZ2V4vj+SuHlzwyJ3ir0r8BdJsEOEJnGE7Tn//MzBFul27bk rkMPHcr3Zx3DlpbHE1qiS5ZEZW/Y0YMPsPofuSxdM7CVU3U0KXkgGOzHjzQlkmxb9NCN D3Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701701868; x=1702306668; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=4s/Fe1XG1yhJb8Cgkf39nJDFir7TwuGaTQXt4MseexI=; b=HLzDe1X+EwJR/xCXTqmQE6Kym2euVA6rWzeef6fSI4QnvcIhFrzZwbnEH7nTr1Fu0V R8vopVO8MiUtKqUSIoet9NMKKtQBaIC78KIly/gVrNmrN3kHGb/HhuD0j2MiRiyBgMYc xQY0VNrBRIfsZcwsFuodjJU6Olmov5HpOgdo2ORZ4gZ2+Cvg6C/ZTsWNy2s/tYl//4DH TJBiSFUo61gBdeuQCqWCDBvfSsfQW27FpMnzMAgHAD5EbIg7MG057pfxBWxg3rnOAR8S QaSOHg4+oiJ95mKXlctxK3JrDll5tPbt7z9wh+FDzUxlymj4hOblQmq7+gIAhgMbLdzl 8j6Q== X-Gm-Message-State: AOJu0Yxni9Ag5fnAX4RbHxYVtyNwIlFEduLXNWAMJOE+hh+HgjoUrSnJ GLWYS0TzHWe3Z38fzw4+w/4= X-Google-Smtp-Source: AGHT+IHzXTkFfcFoLO6wmA/9e59vMmQf4zyM3GFQp9OdUcputmBMTr+GiTkRX07jj2BvW2TDnxIGXw== X-Received: by 2002:a05:620a:269c:b0:77f:4cd:87 with SMTP id c28-20020a05620a269c00b0077f04cd0087mr4856192qkp.86.1701701867639; Mon, 04 Dec 2023 06:57:47 -0800 (PST) Received: from localhost (114.66.194.35.bc.googleusercontent.com. [35.194.66.114]) by smtp.gmail.com with ESMTPSA id x4-20020ae9e904000000b0077d660ac1b6sm4305854qkf.21.2023.12.04.06.57.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 06:57:47 -0800 (PST) Date: Mon, 04 Dec 2023 09:57:47 -0500 From: Willem de Bruijn To: "Song, Yoong Siang" , Jesper Dangaard Brouer , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Bjorn Topel , "Karlsson, Magnus" , "Fijalkowski, Maciej" , Jonathan Lemon , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Stanislav Fomichev , Lorenzo Bianconi , Tariq Toukan , Willem de Bruijn , Maxime Coquelin , Andrii Nakryiko , Mykola Lysenko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Alexandre Torgue , Jose Abreu Message-ID: <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch> In-Reply-To: References: <20231201062421.1074768-1-yoong.siang.song@intel.com> <20231201062421.1074768-3-yoong.siang.song@intel.com> <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: HZEJUDQH3IEQ655GWMXAC5RJU6VN5QIK X-Message-ID-Hash: HZEJUDQH3IEQ655GWMXAC5RJU6VN5QIK X-MailFrom: willemdebruijn.kernel@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "bpf@vger.kernel.org" , "xdp-hints@xdp-project.net" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kselftest@vger.kernel.org" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Song, Yoong Siang wrote: > On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote: > >On 12/1/23 07:24, Song Yoong Siang wrote: > >> This patch enables txtime support to XDP zero copy via XDP Tx > >> metadata framework. > >> > >> Signed-off-by: Song Yoong Siang > >> --- > >> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ > >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++ > >> 2 files changed, 15 insertions(+) > > > >I think we need to see other drivers using this new feature to evaluate > >if API is sane. > > > >I suggest implementing this for igc driver (chip i225) and also for igb > >(i210 chip) that both support this kind of LaunchTime feature in HW. > > > >The API and stmmac driver takes a u64 as time. > >I'm wondering how this applies to i210 that[1] have 25-bit for > >LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5 > >second into the future. > >And i225 that [1] have 30-bit max 1 second into the future. > > > > > >[1] > >https://github.com/xdp-project/xdp- > >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org > > I am using u64 for launch time because existing EDT framework is using it. > Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time. > I choose u64 because ktime_t often requires additional type conversion and > we didn't expect negative value of time. > > include/linux/skbuff.h-744- * @tstamp: Time we arrived/left > include/linux/skbuff.h:745- * @skb_mstamp_ns: (aka @tstamp) earliest departure time; start point > include/linux/skbuff.h-746- * for retransmit timer > -- > include/linux/skbuff.h-880- union { > include/linux/skbuff.h-881- ktime_t tstamp; > include/linux/skbuff.h:882- u64 skb_mstamp_ns; /* earliest departure time */ > include/linux/skbuff.h-883- }; > > tstamp/skb_mstamp_ns are used by various drivers for launch time support > on normal packet, so I think u64 should be "friendly" to all the drivers. For an > example, igc driver will take launch time from tstamp and recalculate it > accordingly (i225 expect user to program "delta time" instead of "time" into > HW register). > > drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp; > drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0); > drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time = igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty); > > Do you think this is enough to say the API is sane? u64 nsec sounds sane to be. It must be made explicit with clock source it is against. Some applications could want to do the conversion from a clock source to raw NIC cycle counter in userspace or BPF and program the raw value. So it may be worthwhile to add an clock source argument -- even if initially only CLOCK_MONOTONIC is supported. See tools/testing/selftests/net/so_txtime.sh for how the FQ and ETF qdiscs already disagree on the clock source that they use.