From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by mail.toke.dk (Postfix) with ESMTPS id D4A9CA43B15 for ; Tue, 5 Dec 2023 19:04:48 +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=RFIqycdS Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-77db736aae5so324111985a.0 for ; Tue, 05 Dec 2023 10:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701799427; x=1702404227; 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=mtqmpldzJhepZSlcxwawCnd6BYpTKMMQiQbo2+VQqDs=; b=RFIqycdS1Y9eKSNyI3QTsl8cZNLzfKszNTfHJCvwRC9LXc1K411J+PC1UFkLHcBzuS cZUj5EbWQdlRk0Ls33VDOVbS7c4RvaaBUSf0am1ZZ+8YiTcKW/mOYeOWM1JiCsCWElgg 2/7nXtYVtXJib2SsCLtPnFaOBs11a6ckg2vcNHDWIRXGLeTP07QbbwKcvY1FsiMtSwNs L5/9ZFqr90nAA0sSLFdMOSyVgIDcG1XHF8qaqdz4/ioQVUuB1kMMQChg9tKRuHwopVxO 3ewn2plmd98PHMAlHpVTZONjtESKrmjq0+y+IihzLFkqi7rTHhsmTiEy/G+jilDNynW9 b/oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701799427; x=1702404227; 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=mtqmpldzJhepZSlcxwawCnd6BYpTKMMQiQbo2+VQqDs=; b=lMee9gfYNx2wF7dnrs0H8jdcYVvuBBP+KBVTPpirlaYokkYgAZs/Y2z5vPIuOn7slz QaqTfylp4GkNHkN0RTboa+HOkdDF9GoAHNBa60EXbcjQvGl9UKcPGQrvSvkCJGiMkI6X 4JBg6l/59YwvzKloSreosr5VVFi3x29d9i19P0q2ygCyp7kgLnK10I4uhbSC84hgpSkg f25ese/DFLUOjPP2FWaa8QJ6pQMIy7kv43bXGxkC56hgzuAa3tOItwwt8bHfUzWQmsj/ CS4upOnAmX+vTNdLskKEi2N1ZoAMIqJ2quf7ClAgHpw0PC4rndWzzhYEUsx/ZAnhJ5KQ r06w== X-Gm-Message-State: AOJu0Yx4wX7ZVWu4ShZ+HsumlirP+9ZPVbbbccvCndHzrIfz+NCLwZ2o Km9MtfjfDzPSf5dUNHF0IkY= X-Google-Smtp-Source: AGHT+IH5nvUqAJXOSA/slhx2XextBvezJuOqw3B1kWvu8x7p9HMI0Usz1QLdc8DahjbJUTB515nU3A== X-Received: by 2002:a05:620a:349:b0:77e:fba3:7574 with SMTP id t9-20020a05620a034900b0077efba37574mr1530842qkm.108.1701799426793; Tue, 05 Dec 2023 10:03:46 -0800 (PST) Received: from localhost (114.66.194.35.bc.googleusercontent.com. [35.194.66.114]) by smtp.gmail.com with ESMTPSA id qh13-20020a05620a668d00b0077d85d22e89sm5264273qkn.63.2023.12.05.10.03.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 10:03:46 -0800 (PST) Date: Tue, 05 Dec 2023 13:03:46 -0500 From: Willem de Bruijn To: Stanislav Fomichev , Florian Bezdeka Message-ID: <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch> In-Reply-To: References: <20231203165129.1740512-1-yoong.siang.song@intel.com> <20231203165129.1740512-3-yoong.siang.song@intel.com> <43b01013-e78b-417e-b169-91909c7309b1@kernel.org> <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch> <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: C3T3OQRJNCFTFFMNFQWHNWMQ4CLOJLTF X-Message-ID-Hash: C3T3OQRJNCFTFFMNFQWHNWMQ4CLOJLTF 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: "Song, Yoong Siang" , Willem de Bruijn , 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 , 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 , "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 v3 2/3] net: stmmac: add Launch Time 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: Stanislav Fomichev wrote: > On Tue, Dec 5, 2023 at 7:34=E2=80=AFAM Florian Bezdeka > wrote: > > > > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote: > > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote: > > > > Jesper Dangaard Brouer wrote: > > > > > > > > > > > > > > > On 12/3/23 17:51, Song Yoong Siang wrote: > > > > > > This patch enables Launch Time (Time-Based Scheduling) suppor= t to XDP zero > > > > > > copy via XDP Tx metadata framework. > > > > > > > > > > > > Signed-off-by: Song Yoong Siang > > > > > > --- > > > > > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ > > > > > > > > > > As requested before, I think we need to see another driver impl= ementing > > > > > this. > > > > > > > > > > I propose driver igc and chip i225. > > > > > > Sure. I will include igc patches in next version. > > > > > > > > > > > > > The interesting thing for me is to see how the LaunchTime max 1= second > > > > > into the future[1] is handled code wise. One suggestion is to a= dd a > > > > > section to Documentation/networking/xsk-tx-metadata.rst per dri= ver that > > > > > mentions/documents these different hardware limitations. It is= natural > > > > > that different types of hardware have limitations. This is a c= lose-to > > > > > hardware-level abstraction/API, and IMHO as long as we document= the > > > > > limitations we can expose this API without too many limitations= for more > > > > > capable hardware. > > > > > > Sure. I will try to add hardware limitations in documentation. > > > > > > > > > > > I would assume that the kfunc will fail when a value is passed th= at > > > > cannot be programmed. > > > > > > > > > > In current design, the xsk_tx_metadata_request() dint got return va= lue. > > > So user won't know if their request is fail. > > > It is complex to inform user which request is failing. > > > Therefore, IMHO, it is good that we let driver handle the error sil= ently. > > > > > > > If the programmed value is invalid, the packet will be "dropped" / wi= ll > > never make it to the wire, right? Programmable behavior is to either drop or cap to some boundary value, such as the farthest programmable time in the future: the horizon. In fq: /* Check if packet timestamp is too far in the future. */= if (fq_packet_beyond_horizon(skb, q, now)) { if (q->horizon_drop) { q->stat_horizon_drops++; return qdisc_drop(skb, sch, to_fr= ee); } q->stat_horizon_caps++; skb->tstamp =3D now + q->horizon; } fq_skb_cb(skb)->time_to_send =3D skb->tstamp; Drop is the more obviously correct mode. Programming with a clock source that the driver does not support will then be a persistent failure. Preferably, this driver capability can be queried beforehand (rather than only through reading error counters afterwards). Perhaps it should not be a driver task to convert from possibly multiple clock sources to the device native clock. Right now, we do use per-device timecounters for this, implemented in the driver. As for which clocks are relevant. For PTP, I suppose the device PHC, converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC. > > > > That is clearly a situation that the user should be informed about. F= or > > RT systems this normally means that something is really wrong regardi= ng > > timing / cycle overflow. Such systems have to react on that situation= . > = > In general, af_xdp is a bit lacking in this 'notify the user that they > somehow messed up' area :-( > For example, pushing a tx descriptor with a wrong addr/len in zc mode > will not give any visible signal back (besides driver potentially > spilling something into dmesg as it was in the mlx case). > We can probably start with having some counters for these events? This is because the AF_XDP completion queue descriptor format is only a u64 address? Could error conditions be reported on tx completion in the metadata, using xsk_tx_metadata_complete?