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.65.226; helo=mta-65-226.siemens.flowmailer.net; envelope-from=fm-68982-20240327112102d41ef2c1384b242e61-qg3_tn@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=CGUw99V0 Received: from mta-65-226.siemens.flowmailer.net (mta-65-226.siemens.flowmailer.net [185.136.65.226]) by mail.toke.dk (Postfix) with ESMTPS id EC529A5CA68 for ; Wed, 27 Mar 2024 12:21:03 +0100 (CET) Received: by mta-65-226.siemens.flowmailer.net with ESMTPSA id 20240327112102d41ef2c1384b242e61 for ; Wed, 27 Mar 2024 12:21:02 +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=FGUoqKxAQrqnoBrdwR+KD2Oip1GwaKOaioEDRMyB75o=; b=CGUw99V0HjizVNE3UApeXPD9+uHHhXmsyZEYTUgE0MzTD4w1Ozpmo4TFQYF8JQH0iggT0x QFWgSKmbprLsTPXnbQNXgj8wqlD6W8TbXgIU71ZoghtuBRT1gnSqTZW9Dee668Vuhvc6h0ls wzj5DDPanluAH3AB7DEsFcAseISXY=; Message-ID: From: Florian Bezdeka To: "Song, Yoong Siang" , Kurt Kanzenbach , "Brandeburg, Jesse" , "Nguyen, Anthony L" , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , "Gomes, Vinicius" , "Fijalkowski, Maciej" Date: Wed, 27 Mar 2024 12:21:01 +0100 In-Reply-To: References: <20240325020928.1987947-1-yoong.siang.song@intel.com> <87h6gtb0p0.fsf@kurt.kurt.home> Autocrypt: =?US-ASCII?Q?addr=3Dflorian.bezdeka@siemen?= =?US-ASCII?Q?s.com;_prefer-encrypt=3Dmutual?= =?US-ASCII?Q?;_keydata=3DmQENBFwsf8QBCAC2f4AQWu92LZC4bKyUYRxWIpWqGz790s?= =?US-ASCII?Q?pcYkXO7M8kfea4iC8qMxv2hT4HT0LTncRP6WiovVN2PeoOBfN5BSa5z?= =?US-ASCII?Q?LIrZGVXh7KmbdKhwhVU+ynoTq9G5uaO2Kos7Vv7nNCuatIq8tSNILuoB?= =?US-ASCII?Q?DFTAZnJW3y1V7YOwhDCPl5gbLSYqUY3OE0yksbtCcVI5istT4ED6mjQ?= =?US-ASCII?Q?9W+3uH1LrgFeEF0oxTjrEPxO5ZYATz0f/TYC8WiM0sMrV+n0eMDntlzA?= =?US-ASCII?Q?63D6lcRi5mNp2jPsJkq3tbWqyCrAe1sKPVJB44ekFwCk0kDIuhR13Q3R?= =?US-ASCII?Q?HE4Or/9sznhMUQjYueWXvTZfzH/VsQJHABEBAAG0LUZsb3JpYW4gQmV6?= =?US-ASCII?Q?ZGVrYSA8Zmxvcmlhbi5iZXpkZWthQHNpZW1lbnMuY29tPokBVAQTAQg?= =?US-ASCII?Q?APhYhBAzL4P3jiTHdthsq4cj0O1fnOEBVBQJcLH/FAhsDBQkB4TOABQs?= =?US-ASCII?Q?JCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEMj0O1fnOEBVc6YIAJ8oO4x?= =?US-ASCII?Q?TjOCpjxaS8XQE6VW50HE9I6ShbQVWUEGhF4qzJaACTQDjdg/aio7qNRa?= =?US-ASCII?Q?mnAy83Hy9sAxKVhXs+1R1fstN+JO8zgD3tJspucUkCiXlYu+Qcv2d6C?= =?US-ASCII?Q?ostv+h4nv8fkSoeLfsQu3GJt6W0RN7t+8H/9fUMXyuB8GWo4bhaZcti6?= =?US-ASCII?Q?78CotGLs6UGZpYEGiAMto8+9zVO/tdY1BkREM6bCVeQ9FnnpTRQy/tU5?= =?US-ASCII?Q?xemMWJI64UUP92TUIbQ3TZKAz4iG/Mle+YjiHBGrJM7TxjE3sDg5J2Fa?= =?US-ASCII?Q?HX4wmZPKGdB6wANKupf6HMMt2y7gduVmMKzgb8PDMLPZwWBSvjELQqz?= =?US-ASCII?Q?hiZAQ0EYLSqZwEIAIR4HMTQC4F4YxatIl6MIDY03zD4M3ZQpgyQ6QFL9?= =?US-ASCII?Q?Dq0I+PGc7A6z5rsGl76+D8pDFSN2BBJiLLlQadxKc3ZyTTlRp4bc=09bf?= =?US-ASCII?Q?FZRmsAXwVfLtBauXxGo9pkyhk8Vcjb2EJm6XR8PH99buGOXlFfTLsmeA?= =?US-ASCII?Q?ji/F4jU3qlUnwZMBvHZwRSFqOGdwKPMvW3FppfmREQ0o4xJ4b/bxGXx?= =?US-ASCII?Q?ko21uyR/S5rEJx6X8Ukw95h3JinXHx/g2cjbKHrWBDKoqtX9IZCamDny?= =?US-ASCII?Q?R+sfLWQbOKOrLNYLwLAQwOTVlZWTgue10G1q6Zi0r8RQ2T1Uy+ZLYagv?= =?US-ASCII?Q?Cbzp/lT7p3mv3ba68llX896c0AEQEAAbQ/QmV6ZGVrYSwgRmxvcmlhbj?= =?US-ASCII?Q?sgQmV6ZGVrYSBGbG9yaWFuIDxmbG9yaWFuLmJlemRla2FAc2llbWVuc?= =?US-ASCII?Q?y5jb20+iQEcBBABCAAGBQJgtKpnAAoJEEoHyE9rG1dPpJYH+gPnqpu7h?= =?US-ASCII?Q?4fsWOxco38e74MsazoUdfndTYP5tgaYTVE51ZhOZBl+4jYaywsmmFm9g?= =?US-ASCII?Q?6N4Tw3GiMEDB4YU1X7gQZ60fDKpYL5SnCu5qZirJ4RCV4LDA0789ir+6?= =?US-ASCII?Q?8/zfwXBTV5QoMH0+MkXB4BL+Km3f7X/GdN5oRoItAyKDBcEfGJo6afT?= =?US-ASCII?Q?PtcUdI9n7ExCSfJwb0SBvvkvUsdNppFDGOOHSioINbEHBs2VUvE43toM?= =?US-ASCII?Q?4mPLfhFIAtDcn5Byt80/kotU8v3Iyf86NYCa+0h77xTsKHcCUqe8Rvow?= =?US-ASCII?Q?bCIbig9GGbbd54TasfqQQOiAkn/WeGl33+UIVX1Q8zo7eyMJHzLJQ3I=3D?= 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: NIEBUCYU7X6ECERAQFXCGNAFMJE7UDLL X-Message-ID-Hash: NIEBUCYU7X6ECERAQFXCGNAFMJE7UDLL X-MailFrom: fm-68982-20240327112102d41ef2c1384b242e61-QG3_TN@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: "intel-wired-lan@lists.osuosl.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "bpf@vger.kernel.org" , "xdp-hints@xdp-project.net" X-Mailman-Version: 3.3.9 Precedence: list Subject: [xdp-hints] Re: [PATCH iwl-next,v4 1/1] igc: Add Tx hardware timestamp request for AF_XDP zero-copy packet List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 2024-03-26 at 14:55 +0000, Song, Yoong Siang wrote: > On Tuesday, March 26, 2024 9:08 PM, Kurt Kanzenbach = wrote: > > Hi Florian, > >=20 > > On Tue Mar 26 2024, Florian Bezdeka wrote: > > > On Mon, 2024-03-25 at 10:09 +0800, Song Yoong Siang wrote: > > > > This patch adds support to per-packet Tx hardware timestamp request= to > > > > AF_XDP zero-copy packet via XDP Tx metadata framework. Please note = that > > > > user needs to enable Tx HW timestamp capability via igc_ioctl() wit= h > > > > SIOCSHWTSTAMP cmd before sending xsk Tx hardware timestamp request. > > > >=20 > > > > Same as implementation in RX timestamp XDP hints kfunc metadata, Ti= mer 0 > > > > (adjustable clock) is used in xsk Tx hardware timestamp. i225/i226 = have > > > > four sets of timestamping registers. *skb and *xsk_tx_buffer pointe= rs > > > > are used to indicate whether the timestamping register is already o= ccupied. > > >=20 > > > Let me make sure that I fully understand that: In my own words: > > >=20 > > > With that applied I'm able to get the point in time from the device > > > when a specific frame made it to the wire. I have to enable that > > > functionality using the mentioned ioctl() call first, and then check > > > the meta area (located in the umem right before the frame payload) > > > while consuming the completion queue/ring. Correct? >=20 > Hi Florian, >=20 > Yes, you are right. But before you pass the frame to driver, make sure > you request Tx metadata hardware timestamp feature by setting > XDP_TXMD_FLAGS_TIMESTAMP flag. > You can refer to tools/testing/selftests/bpf/xdp_hw_metadata.c > on how to do it.=20 Got it. Thanks! >=20 > > >=20 > > > If so, we now have a feedback channel for meta information for/from T= X. > > > Are there any plans - or would it be possible - to support Earliest > > > TxTime First (NET_SCHED_ETF) QDisc based on that channel? In the past > > > we had the problem that we we're missing a feedback channel to > > > communicate back invalid lunch times. > >=20 > > Just asking: How would that work? AFAIK XDP bypasses the Qdisc > > layer. Currently invalid Launch Times are accounted in the ETF Qdisc > > itself. Does that mean every driver has to take care of it? > >=20 > > Thanks, > > Kurt >=20 > Florian & Kurt, >=20 > Yes, me and Stanislav are trying to add Earliest TxTime First / Launch Ti= me to the framework. > Please refer to [1] for the patchset. The metadata framework will just pa= ss the > Launch time value to driver, and driver need to handle the rest. > In the patchset, I am enabling it on stmmac driver only, but we need more= drivers > to check whether the design is feasible for different drivers, cause each= driver is > having their own limitation on launch time. Therefore, after this tx hwts= patch accepted, > I will try to enable launch time on igc driver, and submit new version.= =20 Nice to hear! Keep me in the loop and let me know if I could support somehow. >=20 > Kurt is right that current metadata framework is lacking a way to feedbac= k whether > the launch time is invalid or not. Maybe we can try to enable launch time= without feedback, > then discuss about the status report design. In case the launch time is invalid - couldn't we simply skip the frame and "forward" it back to the application (completion queue/ring) after adjusting some meta-information (like the TX timestamps in this patch) telling the application what happened? Thanks a lot! Florian >=20 > [1] https://patchwork.kernel.org/project/netdevbpf/cover/20231203165129.1= 740512-1-yoong.siang.song@intel.com/ >=20 > Thanks & Regards > Siang