From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) by mail.toke.dk (Postfix) with ESMTPS id 4CF45A43AD8 for ; Tue, 5 Dec 2023 18:13:57 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=L0Fs3iF7 Received: by mail-ua1-x932.google.com with SMTP id a1e0cc1a2514c-7c51dd41046so1258146241.2 for ; Tue, 05 Dec 2023 09:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701796432; x=1702401232; darn=xdp-project.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Jhl4VBonzlc3pWBsupBzGj3hbqoDxmUEBnI+4/Xqy5c=; b=L0Fs3iF7d+zk+6azhmdYzvbkIh4AH2zku7UNDMr1GoFw0MnLYTOHNlmbaJ79HMQF2G IqSMMlhgWveZWJdNmMi3NR1A0epMIF4tiOKKjWFd6r+RilZDpOW4adcv8MxNvMfk6x5Z uKZ8zSk2ItBV6QsiQ1j754eLIsl3XpHUHUg8vcew+zCuwb3zjKYv+oMf7tOc6lYk9Xfk IsSNPdWVEWVD89u9t73micYSBdrv2pKrdzoOkUTLYPkLVBvFFaYIcj+9hXNAUXTssnr9 8GPDuFlk80CcHnVm52teT/OJbxAjMTt1Hq2SFN/7FHxAV+TESMJinFkJe/oJOtjqdiHU /LUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701796432; x=1702401232; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Jhl4VBonzlc3pWBsupBzGj3hbqoDxmUEBnI+4/Xqy5c=; b=l8+I3Eg4A3SEKW1XIPTKLLaGgViKRfALgqhmHj3jGQ4elzFOrnsH1LGPE+N6/rgWHZ 7OmOWeGNG56Vw4JnMjHYNZR6RSXvEyRwSFvsaR0Lxz2kcWPpDJWXJbBBF5lyQ10hiO06 XSSLTQQD7HTOtRlA9SY+CKCSqjk2mRORLeLmAF8+YxLLzbTEM+GfsZJWGMudR++oUW0s s71vp6wkbU04Pbd4JVDRBEYuGQrMJSC6ugLMbqiwClZrDyBGcEeOdJjbj3+iTPN6GQ+m 6inciiAXcbiiR6Ms0Nml8GuXd486b5JuAlJO4sk+zBYAIiJE1rNIvRC5L72hTjW4AoDL bUpQ== X-Gm-Message-State: AOJu0YylIeCBvCQwqh2KEDgA2JIyPSnOBTyIeHPUAKHloaywGHoYntM4 U344CGcx2KX/PyHR+QF+v/6+TLzHpnxNLS0bB8VJ4g== X-Google-Smtp-Source: AGHT+IGZ2g2oFmmMcDVzmGa+ZZi/Dz9EWTryACUv6KZTkY8C1ML9of935relBOPEXVeT256piz2KyEWvu0yNMvy9fmw= X-Received: by 2002:a1f:fc83:0:b0:4b2:7fa3:a965 with SMTP id a125-20020a1ffc83000000b004b27fa3a965mr4904643vki.11.1701796432618; Tue, 05 Dec 2023 09:13:52 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com> From: Stanislav Fomichev Date: Tue, 5 Dec 2023 09:13:39 -0800 Message-ID: To: Florian Bezdeka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: N6JM4NAZOAH4SX4H26TB4FT2XPK32YAN X-Message-ID-Hash: N6JM4NAZOAH4SX4H26TB4FT2XPK32YAN X-MailFrom: sdf@google.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: 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) support 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 implemen= ting > > > > 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 sec= ond > > > > into the future[1] is handled code wise. One suggestion is to add a > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver = that > > > > mentions/documents these different hardware limitations. It is nat= ural > > > > that different types of hardware have limitations. This is a close= -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 that > > > cannot be programmed. > > > > > > > In current design, the xsk_tx_metadata_request() dint got return value. > > 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 silentl= y. > > > > If the programmed value is invalid, the packet will be "dropped" / will > never make it to the wire, right? > > That is clearly a situation that the user should be informed about. For > RT systems this normally means that something is really wrong regarding > 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?