From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=rts-flowmailer.siemens.com (client-ip=185.136.64.228; helo=mta-64-228.siemens.flowmailer.net; envelope-from=fm-68982-2023120515343262ab859a894f025b11-b_7qnq@rts-flowmailer.siemens.com; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; secure) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.a=rsa-sha256 header.s=fm1 header.b=J+8+bbFX Received: from mta-64-228.siemens.flowmailer.net (mta-64-228.siemens.flowmailer.net [185.136.64.228]) by mail.toke.dk (Postfix) with ESMTPS id 853E3A43A67 for ; Tue, 5 Dec 2023 16:34:34 +0100 (CET) Received: by mta-64-228.siemens.flowmailer.net with ESMTPSA id 2023120515343262ab859a894f025b11 for ; Tue, 05 Dec 2023 16:34:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=florian.bezdeka@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=QLrrt7aQd3uFEGTkO/x97Sh3we90ObbwSexb6iVGv7A=; b=J+8+bbFXw8iqevTZ/1LFxb77bPK9BAi2TmeskopxbHBkn5POqgmVNCOYGcqwEep7uOPJpl zj+FDvGwqPNeHsljWo0kiWzfDFu9PDhQN6eGhzaJB7XFPDStPDo9SmhEyvxSfz3Nw8ezFswW bfVo1XvFDjaGtWxsO3vjq4Ss0mo2w=; Message-ID: <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com> From: Florian Bezdeka To: "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 , 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 Date: Tue, 05 Dec 2023 16:34:29 +0100 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer Message-ID-Hash: 5XJ4JL3XDKBEV2QDZSHHBOMCKF2UJNC7 X-Message-ID-Hash: 5XJ4JL3XDKBEV2QDZSHHBOMCKF2UJNC7 X-MailFrom: fm-68982-2023120515343262ab859a894f025b11-B_7Qnq@rts-flowmailer.siemens.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 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, 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: > > >=20 > > >=20 > > > On 12/3/23 17:51, Song Yoong Siang wrote: > > > > This patch enables Launch Time (Time-Based Scheduling) support to X= DP zero > > > > copy via XDP Tx metadata framework. > > > >=20 > > > > Signed-off-by: Song Yoong Siang > > > > --- > > > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ > > >=20 > > > As requested before, I think we need to see another driver implementi= ng > > > this. > > >=20 > > > I propose driver igc and chip i225. >=20 > Sure. I will include igc patches in next version. >=20 > > >=20 > > > The interesting thing for me is to see how the LaunchTime max 1 secon= d > > > into the future[1] is handled code wise. One suggestion is to add a > > > section to Documentation/networking/xsk-tx-metadata.rst per driver th= at > > > mentions/documents these different hardware limitations. It is natur= al > > > that different types of hardware have limitations. This is a close-t= o > > > hardware-level abstraction/API, and IMHO as long as we document the > > > limitations we can expose this API without too many limitations for m= ore > > > capable hardware. >=20 > Sure. I will try to add hardware limitations in documentation.=20 >=20 > >=20 > > I would assume that the kfunc will fail when a value is passed that > > cannot be programmed. > >=20 >=20 > In current design, the xsk_tx_metadata_request() dint got return value.= =20 > So user won't know if their request is fail.=20 > It is complex to inform user which request is failing.=20 > Therefore, IMHO, it is good that we let driver handle the error silently. >=20 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. > =20 >=20 > > What is being implemented here already exists for qdiscs. The FQ > > qdisc takes a horizon attribute and > >=20 > > " > > when a packet is beyond the horizon > > at enqueue() time: > > - either drop the packet (default policy) > > - or cap its delivery time to the horizon. > > " > > commit 39d010504e6b ("net_sched: sch_fq: add horizon attribute") > >=20 > > Having the admin manually configure this on the qdisc based on > > off-line knowledge of the device is more fragile than if the device > > would somehow signal its limit to the stack. > >=20 > > But I don't think we should add enforcement of that as a requirement > > for this xdp extension of pacing.