From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by mail.toke.dk (Postfix) with ESMTPS id CD59CA5C776 for ; Tue, 26 Mar 2024 14:08:13 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=Q3BPGshZ; dkim=pass (512-bit key; secure) header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=ETN1EH6y From: Kurt Kanzenbach DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1711458493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EFshh7X9ubM0+XF5Ra6jL39fGH/o4V6QpqW2xLYoLl4=; b=Q3BPGshZjYjwajuB08w+lCsgYc4jwV721Wv5kUoUeHfAFvZkyxyndQHGFurpE95oBdR4bX YpJjFXDFZWJr7xwnkfmW3FHTGgNjgbHxVo3KcAN7n83/W4ps0adlGOwyu50R0Qk+O2a69N 1xd2Ccp638kp4wALLynd+IL5F4zUqBdo/2mYwtWONS/L22/bdK2/pCCoK6Eqvs0u3M8Gzu Gotov/THQ8uRTkAP5UACHcIJVGxVQLYm0FD6D/oxxhY3szI+2N/c0ILavEIEfPDdTbHsm9 PGQnH1iJAOWK1xQbzQTOCcciMsApeSFTClTAJR6WzEw1cNDufscUg0zVIcQDqQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1711458493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EFshh7X9ubM0+XF5Ra6jL39fGH/o4V6QpqW2xLYoLl4=; b=ETN1EH6yWipj0JNpAd5nRCoQV2L5x2Mn9uiIkmMkcszRTyQQ0yU/InWK3ccY47SVq72IP1 H6ZpPfeK79IJ7wAg== To: Florian Bezdeka , Song Yoong Siang , Jesse Brandeburg , Tony Nguyen , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Vinicius Costa Gomes , Maciej Fijalkowski In-Reply-To: References: <20240325020928.1987947-1-yoong.siang.song@intel.com> Date: Tue, 26 Mar 2024 14:08:11 +0100 Message-ID: <87h6gtb0p0.fsf@kurt.kurt.home> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: V5NLU3GC66WOHOYFON2GZJYQWIV72OFM X-Message-ID-Hash: V5NLU3GC66WOHOYFON2GZJYQWIV72OFM X-MailFrom: kurt@linutronix.de 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: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Florian, 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() with >> SIOCSHWTSTAMP cmd before sending xsk Tx hardware timestamp request. >>=20 >> Same as implementation in RX timestamp XDP hints kfunc metadata, Timer 0 >> (adjustable clock) is used in xsk Tx hardware timestamp. i225/i226 have >> four sets of timestamping registers. *skb and *xsk_tx_buffer pointers >> are used to indicate whether the timestamping register is already occupi= ed. > > Let me make sure that I fully understand that: In my own words: > > 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? > > If so, we now have a feedback channel for meta information for/from TX. > 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. 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? Thanks, Kurt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEEvLm/ssjDfdPf21mSwZPR8qpGc4IFAmYCyLsTHGt1cnRAbGlu dXRyb25peC5kZQAKCRDBk9HyqkZzggJ7D/9ZO6iQENtqCYv6/eWBp7S7wfIxVTnA /O1AKCo1zVKtj0of1aR/1pAf1BsbmZNpYXHf0bTL74M6gzJtxRJDb+X9TX++wIRP TBAKlWuIiOMTRgKJ6b8lO9Jv3MExJ7WOJDarXI7wFHsgUEwZ4XgDRf+v550KVztw t1qEskkv0SCqZsidryG19aSwECAlvkie5JPX6WS5YuvmWRg6Gj4P8GKXUctHakfW z2O/mFbuq+fkAsYRA1MLXQw+uVliEoSbNaMkUCC6bH2MmAHJPs9rrmXqTMuWz5tK lTA4sh/OYTPJWhqvEPlJp3aCmgDmvd3VyEhxJPdnYdzhPCQ6CG+D4A5hzKjNC0eq Dw3UR7Gqsa4lpSrwUOcGZjtmdUQbH+lsKgekCZq/FQeU4McrWGWDJSRHC9Ak6Wge Zuh2KmRx7+8TynukUG+mZq0pso+F8bABY0/CK6ftt3KXhq3pS/jsMUZK6FQ0ASXP 8PFU8imBZQorzkKnXfQv4VD9ZtXuWA9eJ2ipGFCrg2a4BEcVltXEqgy1u0yysZtZ Ajj/R8KvMplogG2/MSg4QS6mYxWd4sPGa8TmpSr+h4TPM+x5prFInVhTUTlUyt/D 2+uooj7jtx07znqgPaMRrRSitxd/qGxEMW+qwNwzDgpSiKFmSyftE0A9UPBo/nSP SqzH1kto/s6nmw== =EfO9 -----END PGP SIGNATURE----- --=-=-=--