Message ID | 20231201062421.1074768-1-yoong.siang.song@intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp915262vqy; Thu, 30 Nov 2023 22:24:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IH9MY1srxAlhrnKp+AKlg/g1ZSsfOOnYD6irpgsQUo+cxtiznJqQD9O2in3k9xd4zgt9ZKM X-Received: by 2002:a05:6a00:2da8:b0:6cd:fa30:f52 with SMTP id fb40-20020a056a002da800b006cdfa300f52mr2789466pfb.9.1701411891418; Thu, 30 Nov 2023 22:24:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701411891; cv=none; d=google.com; s=arc-20160816; b=A4X62IR33n4Yguh9GPA5xspmNupbZZEMvr3rEkPXe1ShIOs4324Ds75GDhc5fjRKde O6Ovnzfg2wTTltp07G9zXKut+LvuEvjueWcOsTZTrsdcdDCF/9dTl3740Y1P6S+6aKN7 YPA3+i+c9K/lGH2FqCK68n6iV12GiQy+xw58Ja2bAzm8UT0bFH5SOuZmEMg6HG3rGtPH NKEkklL/Tv9ELBxuqWwAYLZXtWhP5q3p7jRV5ApVKuj6W5pQsVQeGm2KsjKvARU4i3IL gHBmCH7K5Dqr9jWBRy7dumrKwL+JYVd389lpag9DXlJ7vls3ruVlTSxZJmpLghAuypU2 wYMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=GzazURHK/ywqMW6teLEqg7mvgPspy6AY7vIzipy1KOI=; fh=YTkuaskr0lgfdZdN3raKefSjBLb6uuCywA/U9wJpjjU=; b=gQHs/2I0SKA9bHI00LB9bUGnfQBF+BeiFJDR4OJC+r5+mo8T1qgmm2SlngVFxmQVYK KcoO/BHYYFZH74OUpUN/6ZkraCfaZPzMSvtkZm+cmUscfZS6QXSMXupN/wpHmUJT3Ni9 Vmn/zoPtUYZQ/8CrWBHnWZejt/h+YMEtn4EOEMjKdWCWSc/ImA5X5UFb4xf0YD3weP3p HHa4UALvH7OPhxNMscS/0PI5M4K2au5uXJMNyVmiv5IhZh40OGxWvAPooOzkUWnmoCNz kwPW1kyJG1KvWoUpwwuQ02NL7fRPzY3ZwEkpRo2m4fC200t8t7NS3BXwlt6OGEhtooxm 7XDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Zag7mclo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id x20-20020a63fe54000000b005bdfd3a269fsi2713950pgj.581.2023.11.30.22.24.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 22:24:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Zag7mclo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id D7A6E8145961; Thu, 30 Nov 2023 22:24:46 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229520AbjLAGYi (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Fri, 1 Dec 2023 01:24:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbjLAGYh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 1 Dec 2023 01:24:37 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 774FA1718; Thu, 30 Nov 2023 22:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701411883; x=1732947883; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=OrXONeV7YlBRhiTW3LB5rHkzQDQL8wPC8aPc0x4910w=; b=Zag7mclosS6/OwdbIaP6Xff5DAUvlz5TUY5nFCBZrpRXDa1a/PhvjlYt WSvVaAgfw1HJLiCrKcMyfTSYiztdJCuGxC6ga2XEseuX84lZy/yRxOHqS dSjTlB/ZyvLRwd1St35D5gg7sdUCn+CO0wlgvYnd041kb84oGWQ2qpn/b azFFCGJj0EPeVESlFvHQf/Ey2rhZRarQdwiVvmC6ebjRO34E9fpDKKyVM d+aX3lpBp7sg/bLoaDCkiPQy2uKKZ4rnbC2jIe6xg2vLQpijy+sSJVDDo tINh/0AgBbzRfn6o9UrENXwWM7JCO9LGn2pclK/H/OXyyQNuOvQd/8Yd+ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10910"; a="6722778" X-IronPort-AV: E=Sophos;i="6.04,241,1695711600"; d="scan'208";a="6722778" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2023 22:24:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10910"; a="803945044" X-IronPort-AV: E=Sophos;i="6.04,241,1695711600"; d="scan'208";a="803945044" Received: from p12ill20yoongsia.png.intel.com ([10.88.227.28]) by orsmga001.jf.intel.com with ESMTP; 30 Nov 2023 22:24:31 -0800 From: Song Yoong Siang <yoong.siang.song@intel.com> To: "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Jonathan Corbet <corbet@lwn.net>, Bjorn Topel <bjorn@kernel.org>, Magnus Karlsson <magnus.karlsson@intel.com>, Maciej Fijalkowski <maciej.fijalkowski@intel.com>, Jonathan Lemon <jonathan.lemon@gmail.com>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Jesper Dangaard Brouer <hawk@kernel.org>, John Fastabend <john.fastabend@gmail.com>, Stanislav Fomichev <sdf@google.com>, Lorenzo Bianconi <lorenzo@kernel.org>, Tariq Toukan <tariqt@nvidia.com>, Willem de Bruijn <willemb@google.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Andrii Nakryiko <andrii@kernel.org>, Mykola Lysenko <mykolal@fb.com>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu <song@kernel.org>, Yonghong Song <yonghong.song@linux.dev>, KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com> 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, Song Yoong Siang <yoong.siang.song@intel.com> Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support Date: Fri, 1 Dec 2023 14:24:18 +0800 Message-Id: <20231201062421.1074768-1-yoong.siang.song@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 30 Nov 2023 22:24:47 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784059675592674952 X-GMAIL-MSGID: 1784059675592674952 |
Series |
xsk: TX metadata txtime support
|
|
Message
Song Yoong Siang
Dec. 1, 2023, 6:24 a.m. UTC
This series expands XDP TX metadata framework to include ETF HW offload. Changes since v1: - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) - rename launch-time to txtime v1: https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1-yoong.siang.song@intel.com/ Song Yoong Siang (3): xsk: add ETF support to XDP Tx metadata net: stmmac: Add txtime support to XDP ZC selftests/bpf: Add txtime to xdp_hw_metadata Documentation/netlink/specs/netdev.yaml | 4 ++++ Documentation/networking/xsk-tx-metadata.rst | 5 +++++ drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ .../net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++ include/net/xdp_sock.h | 9 +++++++++ include/net/xdp_sock_drv.h | 1 + include/uapi/linux/if_xdp.h | 9 +++++++++ include/uapi/linux/netdev.h | 3 +++ net/core/netdev-genl.c | 2 ++ net/xdp/xsk.c | 3 +++ tools/include/uapi/linux/if_xdp.h | 9 +++++++++ tools/include/uapi/linux/netdev.h | 3 +++ tools/net/ynl/generated/netdev-user.c | 1 + tools/testing/selftests/bpf/xdp_hw_metadata.c | 18 +++++++++++++++++- 14 files changed, 81 insertions(+), 1 deletion(-)
Comments
On 12/1/23 07:24, Song Yoong Siang wrote: > This series expands XDP TX metadata framework to include ETF HW offload. > > Changes since v1: > - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) > - rename launch-time to txtime > I strongly disagree with this renaming (sorry to disagree with Willem). The i210 and i225 chips call this LaunchTime in their programmers datasheets, and even in the driver code[1]. Using this "txtime" name in the code is also confusing, because how can people reading the code know the difference between: - tmo_request_timestamp and tmo_request_txtime [1] https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org > v1: https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1-yoong.siang.song@intel.com/ > > Song Yoong Siang (3): > xsk: add ETF support to XDP Tx metadata > net: stmmac: Add txtime support to XDP ZC > selftests/bpf: Add txtime to xdp_hw_metadata > > Documentation/netlink/specs/netdev.yaml | 4 ++++ > Documentation/networking/xsk-tx-metadata.rst | 5 +++++ > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++ > include/net/xdp_sock.h | 9 +++++++++ > include/net/xdp_sock_drv.h | 1 + > include/uapi/linux/if_xdp.h | 9 +++++++++ > include/uapi/linux/netdev.h | 3 +++ > net/core/netdev-genl.c | 2 ++ > net/xdp/xsk.c | 3 +++ > tools/include/uapi/linux/if_xdp.h | 9 +++++++++ > tools/include/uapi/linux/netdev.h | 3 +++ > tools/net/ynl/generated/netdev-user.c | 1 + > tools/testing/selftests/bpf/xdp_hw_metadata.c | 18 +++++++++++++++++- > 14 files changed, 81 insertions(+), 1 deletion(-) >
On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk@kernel.org> wrote: >On 12/1/23 07:24, Song Yoong Siang wrote: >> This series expands XDP TX metadata framework to include ETF HW offload. >> >> Changes since v1: >> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) >> - rename launch-time to txtime >> > >I strongly disagree with this renaming (sorry to disagree with Willem). > >The i210 and i225 chips call this LaunchTime in their programmers >datasheets, and even in the driver code[1]. > >Using this "txtime" name in the code is also confusing, because how can >people reading the code know the difference between: > - tmo_request_timestamp and tmo_request_txtime > Hi Jesper and Willem, How about using "launch_time" for the flag/variable and "Earliest TxTime First" for the description/comments? Thanks & Regards Siang > >[1] >https://github.com/xdp-project/xdp- >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org > >> v1: >https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1- >yoong.siang.song@intel.com/ >> >> Song Yoong Siang (3): >> xsk: add ETF support to XDP Tx metadata >> net: stmmac: Add txtime support to XDP ZC >> selftests/bpf: Add txtime to xdp_hw_metadata >> >> Documentation/netlink/specs/netdev.yaml | 4 ++++ >> Documentation/networking/xsk-tx-metadata.rst | 5 +++++ >> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ >> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++ >> include/net/xdp_sock.h | 9 +++++++++ >> include/net/xdp_sock_drv.h | 1 + >> include/uapi/linux/if_xdp.h | 9 +++++++++ >> include/uapi/linux/netdev.h | 3 +++ >> net/core/netdev-genl.c | 2 ++ >> net/xdp/xsk.c | 3 +++ >> tools/include/uapi/linux/if_xdp.h | 9 +++++++++ >> tools/include/uapi/linux/netdev.h | 3 +++ >> tools/net/ynl/generated/netdev-user.c | 1 + >> tools/testing/selftests/bpf/xdp_hw_metadata.c | 18 +++++++++++++++++- >> 14 files changed, 81 insertions(+), 1 deletion(-) >>
Song, Yoong Siang wrote: > On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk@kernel.org> wrote: > >On 12/1/23 07:24, Song Yoong Siang wrote: > >> This series expands XDP TX metadata framework to include ETF HW offload. > >> > >> Changes since v1: > >> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) > >> - rename launch-time to txtime > >> > > > >I strongly disagree with this renaming (sorry to disagree with Willem). > > > >The i210 and i225 chips call this LaunchTime in their programmers > >datasheets, and even in the driver code[1]. > > > >Using this "txtime" name in the code is also confusing, because how can > >people reading the code know the difference between: > > - tmo_request_timestamp and tmo_request_txtime > > > > Hi Jesper and Willem, > > How about using "launch_time" for the flag/variable and > "Earliest TxTime First" for the description/comments? I don't particularly care which term we use, as long as we're consistent. Especially, don't keep introducing new synonyms. The fact that one happens to be one vendor's marketing term does not make it preferable, IMHO. On the contrary. SO_TXTIME is in the ABI, and EDT has been used publicly in kernel patches and conference talks, e.g., Van Jacobson's Netdev 0x12 keynote. Those are vendor agnostic commonly used terms. But as long as Launch Time is not an Intel only trademark, fine to select that.
On 12/1/23 16:09, Willem de Bruijn wrote: > Song, Yoong Siang wrote: >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk@kernel.org> wrote: >>> On 12/1/23 07:24, Song Yoong Siang wrote: >>>> This series expands XDP TX metadata framework to include ETF HW offload. >>>> >>>> Changes since v1: >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) >>>> - rename launch-time to txtime >>>> >>> >>> I strongly disagree with this renaming (sorry to disagree with Willem). >>> >>> The i210 and i225 chips call this LaunchTime in their programmers >>> datasheets, and even in the driver code[1]. >>> >>> Using this "txtime" name in the code is also confusing, because how can >>> people reading the code know the difference between: >>> - tmo_request_timestamp and tmo_request_txtime >>> >> >> Hi Jesper and Willem, >> >> How about using "launch_time" for the flag/variable and >> "Earliest TxTime First" for the description/comments? > I don't follow why you are calling the feature: - "Earliest TxTime First" (ETF). - AFAIK this just reference an qdisc name (that most don't know exists) > I don't particularly care which term we use, as long as we're > consistent. Especially, don't keep introducing new synonyms. > > The fact that one happens to be one vendor's marketing term does not > make it preferable, IMHO. On the contrary. > These kind of hardware features are defined as part of Time Sensitive Networking (TSN). I believe these TSN features are defined as part of IEEE 802.1Qbv (2015) and according to Wikipedia[2] incorporated into IEEE 802.1Q. [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel > patches and conference talks, e.g., Van Jacobson's Netdev 0x12 > keynote. Those are vendor agnostic commonly used terms. > I agree that EDT (Earliest Departure Time) have become a thing and term in our community. We could associate this feature with this. I do fear what hardware behavior will be it if I e.g. ask it to send a packet 2 sec in the future on i225 which max support 1 sec. Will hardware send it at 1 sec? Because then I'm violating the *Earliest* Departure Time. > But as long as Launch Time is not an Intel only trademark, fine to > select that. The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I don't like to for us to name this after this. This features is simply taking advantage of exposing one of the hardware building blocks (controlling/setting packet "launch time") that can be used for implementing a TAS. I like the name "launch time" because it doesn't get easily confused with other timestamps, and intuitively describes packet will be send at a specific time (likely in future). --Jesper
Jesper Dangaard Brouer wrote: > > > On 12/1/23 16:09, Willem de Bruijn wrote: > > Song, Yoong Siang wrote: > >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk@kernel.org> wrote: > >>> On 12/1/23 07:24, Song Yoong Siang wrote: > >>>> This series expands XDP TX metadata framework to include ETF HW offload. > >>>> > >>>> Changes since v1: > >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) > >>>> - rename launch-time to txtime > >>>> > >>> > >>> I strongly disagree with this renaming (sorry to disagree with Willem). > >>> > >>> The i210 and i225 chips call this LaunchTime in their programmers > >>> datasheets, and even in the driver code[1]. > >>> > >>> Using this "txtime" name in the code is also confusing, because how can > >>> people reading the code know the difference between: > >>> - tmo_request_timestamp and tmo_request_txtime > >>> > >> > >> Hi Jesper and Willem, > >> > >> How about using "launch_time" for the flag/variable and > >> "Earliest TxTime First" for the description/comments? > > > > I don't follow why you are calling the feature: > - "Earliest TxTime First" (ETF). > - AFAIK this just reference an qdisc name (that most don't know exists) > > > > I don't particularly care which term we use, as long as we're > > consistent. Especially, don't keep introducing new synonyms. > > > > The fact that one happens to be one vendor's marketing term does not > > make it preferable, IMHO. On the contrary. > > > > These kind of hardware features are defined as part of Time Sensitive > Networking (TSN). > I believe these TSN features are defined as part of IEEE 802.1Qbv (2015) > and according to Wikipedia[2] incorporated into IEEE 802.1Q. > > [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking > > > > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel > > patches and conference talks, e.g., Van Jacobson's Netdev 0x12 > > keynote. Those are vendor agnostic commonly used terms. > > > > I agree that EDT (Earliest Departure Time) have become a thing and term > in our community. > We could associate this feature with this. > I do fear what hardware behavior will be it if I e.g. ask it to send a > packet 2 sec in the future on i225 which max support 1 sec. > Will hardware send it at 1 sec? > Because then I'm violating the *Earliest* Departure Time. That should definitely not happen. At least not on a device that implements EDT semantics. This relates to Jakub's question in the previous thread on whether this mechanism allows out-of-order transmission or maintains FIFO behavior. That really is device specific. Older devices only support this for low rate (PTP) and with a small fixed number of outstanding requests. For pacing offload, devices need to support up to linerate and out-of-order. I don't think we want to enforce either in software, as the hardware is already out there. But it would be good if drivers can somehow label these capabilities. Including programmable horizon. It is up to the qdisc to ensure that it does not pass packets to the device beyond its horizon. ETF and FQ already have a concept of horizon. And a way to queue errors for packets out of bound (SO_EE_CODE_TXTIME_..). > > > But as long as Launch Time is not an Intel only trademark, fine to > > select that. > > The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I > don't like to for us to name this after this. This features is simply > taking advantage of exposing one of the hardware building blocks > (controlling/setting packet "launch time") that can be used for > implementing a TAS. > > I like the name "launch time" because it doesn't get easily confused > with other timestamps, and intuitively describes packet will be send at > a specific time (likely in future). > > --Jesper Understood on your point that txtime and tx_timestamp are too similar. As said, I don't care strongly. Launch time sounds fine to me. Others can speak up if they disagree. I take launch time as a less strict than EDT: it is a request to send at a certain time, with no strict definition on uncertainty. While EDT more strictly ensures that a packet is not sent before the timestamp.
On Saturday, December 2, 2023 10:16 PM, Willem de Bruijn wrote: >Jesper Dangaard Brouer wrote: >> >> >> On 12/1/23 16:09, Willem de Bruijn wrote: >> > Song, Yoong Siang wrote: >> >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer ><hawk@kernel.org> wrote: >> >>> On 12/1/23 07:24, Song Yoong Siang wrote: >> >>>> This series expands XDP TX metadata framework to include ETF HW offload. >> >>>> >> >>>> Changes since v1: >> >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF) >> >>>> - rename launch-time to txtime >> >>>> >> >>> >> >>> I strongly disagree with this renaming (sorry to disagree with Willem). >> >>> >> >>> The i210 and i225 chips call this LaunchTime in their programmers >> >>> datasheets, and even in the driver code[1]. >> >>> >> >>> Using this "txtime" name in the code is also confusing, because how can >> >>> people reading the code know the difference between: >> >>> - tmo_request_timestamp and tmo_request_txtime >> >>> >> >> >> >> Hi Jesper and Willem, >> >> >> >> How about using "launch_time" for the flag/variable and >> >> "Earliest TxTime First" for the description/comments? >> > >> >> I don't follow why you are calling the feature: >> - "Earliest TxTime First" (ETF). >> - AFAIK this just reference an qdisc name (that most don't know exists) >> >> >> > I don't particularly care which term we use, as long as we're >> > consistent. Especially, don't keep introducing new synonyms. >> > >> > The fact that one happens to be one vendor's marketing term does not >> > make it preferable, IMHO. On the contrary. >> > >> >> These kind of hardware features are defined as part of Time Sensitive >> Networking (TSN). >> I believe these TSN features are defined as part of IEEE 802.1Qbv (2015) >> and according to Wikipedia[2] incorporated into IEEE 802.1Q. >> >> [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking >> >> >> > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel >> > patches and conference talks, e.g., Van Jacobson's Netdev 0x12 >> > keynote. Those are vendor agnostic commonly used terms. >> > >> >> I agree that EDT (Earliest Departure Time) have become a thing and term >> in our community. >> We could associate this feature with this. >> I do fear what hardware behavior will be it if I e.g. ask it to send a >> packet 2 sec in the future on i225 which max support 1 sec. >> Will hardware send it at 1 sec? >> Because then I'm violating the *Earliest* Departure Time. > >That should definitely not happen. At least not on a device that >implements EDT semantics. > >This relates to Jakub's question in the previous thread on whether >this mechanism allows out-of-order transmission or maintains FIFO >behavior. That really is device specific. > >Older devices only support this for low rate (PTP) and with a small >fixed number of outstanding requests. For pacing offload, devices need >to support up to linerate and out-of-order. > >I don't think we want to enforce either in software, as the hardware >is already out there. But it would be good if drivers can somehow >label these capabilities. Including programmable horizon. > >It is up to the qdisc to ensure that it does not pass packets to the >device beyond its horizon. > >ETF and FQ already have a concept of horizon. And a way to queue >errors for packets out of bound (SO_EE_CODE_TXTIME_..). > >> >> > But as long as Launch Time is not an Intel only trademark, fine to >> > select that. >> >> The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I >> don't like to for us to name this after this. This features is simply >> taking advantage of exposing one of the hardware building blocks >> (controlling/setting packet "launch time") that can be used for >> implementing a TAS. >> >> I like the name "launch time" because it doesn't get easily confused >> with other timestamps, and intuitively describes packet will be send at >> a specific time (likely in future). >> >> --Jesper > >Understood on your point that txtime and tx_timestamp are too similar. >As said, I don't care strongly. Launch time sounds fine to me. Others >can speak up if they disagree. > >I take launch time as a less strict than EDT: it is a request to send >at a certain time, with no strict definition on uncertainty. While EDT >more strictly ensures that a packet is not sent before the timestamp. Thanks for the deep discussion and information. I agree with launch time too. I will submit v3 with launch time so that others can review on the new naming and provide their feedback.