From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E8D9CC4167B for ; Tue, 5 Dec 2023 15:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=A2MVEsrW4pDmYtc/2A9ogSjvrmBZgI+bH868eTjZ5Tk=; b=uSaLh81IGKXUCI 3VitjdwGnaHmR2T4GSLDVTTRsjmOdwBqvCSHUYATUNYAu/1OMEcvTx5puVVAeQiyzHa361sSsz2h0 +s7kxcmCyJKizbf4WbLELCKH0AI/cohLOutlrki6RhFAsPggBZ0Vp3BlhPRaugPdHmrQn2gKbQEv+ xMGXiVNOiSqLxT2QeLZQwR/u/YT/wy1C2sYTiP8OAK+CKK+CUFDhzS/yFyPOuQHYWjFglYwgT0BCC HRVWhu9fm2Ka2G6QmpzQw3/RVSFAomVn78osKtdSe7dCVjVVyllKyO4mHo5I9vj8uMRB4aTB/EtZD tUnbxKTXpETnSztu9VVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rAXRf-007lxG-0a; Tue, 05 Dec 2023 15:34:47 +0000 Received: from mta-65-226.siemens.flowmailer.net ([185.136.65.226]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rAXRa-007lvU-0w for linux-arm-kernel@lists.infradead.org; Tue, 05 Dec 2023 15:34:45 +0000 Received: by mta-65-226.siemens.flowmailer.net with ESMTPSA id 20231205153432d8a645d14cf48d69f9 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> Subject: Re: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch Time support to XDP ZC 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 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" 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> MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231205_073443_291374_769F69BC X-CRM114-Status: GOOD ( 28.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 implementing > > > 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 add a > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that > > > mentions/documents these different hardware limitations. It is natural > > > 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 silently. > 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. > > > > What is being implemented here already exists for qdiscs. The FQ > > qdisc takes a horizon attribute and > > > > " > > 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") > > > > 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. > > > > But I don't think we should add enforcement of that as a requirement > > for this xdp extension of pacing. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel