From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mail.toke.dk (Postfix) with ESMTPS id DD50C9A7AFC for ; Wed, 5 Oct 2022 03:24:55 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=WKQHqRrz Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D86736155D; Wed, 5 Oct 2022 01:24:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5989C433C1; Wed, 5 Oct 2022 01:24:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664933093; bh=+SpVYMQRSVDzl8SG19hqiLp1I5AQ70apCqU8oshGPJM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WKQHqRrzQQZJfurmJD6DcH0ziQtGbJ9UW4cQ215XFFo6LsxY7hAqccXqE+XQzHBm7 xjIxcDO03Q/Pjb/hUm8ZFAe4H07i2tkOC+Y5ulwxKrVb1TRvheDp9OaKYVIjlB1VHi VZY6BHdSu8lis6980huPBLROSrk51QjR3SMBGsAfq1jNr/DFSpSBTxINQn12znbtJ1 D0WiJBhDuBva/C7HCkIhi+onA3iwFsrwlFgVtQUkx/SdkwhIC33yvEFkt+pqj+4HOU t1kUwTYvuUBukz2qS0UMOKcOealDb6NhhcIlvaeZanAwFSUIZoSipJ/D3rpOwJDa2Z gEGg1X+Uo3f/w== Date: Tue, 4 Oct 2022 18:24:51 -0700 From: Jakub Kicinski To: Stanislav Fomichev Message-ID: <20221004182451.6804b8ca@kernel.org> In-Reply-To: References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <35fcfb25-583a-e923-6eee-e8bbcc19db17@redhat.com> <5ccff6fa-0d50-c436-b891-ab797fe7e3c4@linux.dev> <20221004175952.6e4aade7@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FYCIZWQNLIVJTDPFCQ2I3OMA6U5NQO4L X-Message-ID-Hash: FYCIZWQNLIVJTDPFCQ2I3OMA6U5NQO4L X-MailFrom: kuba@kernel.org 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: Martin KaFai Lau , Jesper Dangaard Brouer , brouer@redhat.com, bpf@vger.kernel.org, netdev@vger.kernel.org, xdp-hints@xdp-project.net, larysa.zaremba@intel.com, memxor@gmail.com, Lorenzo Bianconi , mtahhan@redhat.com, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , dave@dtucker.co.uk, Magnus Karlsson , bjorn@kernel.org X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFCv2 bpf-next 00/18] XDP-hints: XDP gaining access to HW offload hints via BTF List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 4 Oct 2022 18:02:56 -0700 Stanislav Fomichev wrote: > +1, sounds like a good alternative (got your reply while typing) > I'm not too versed in the rx_desc/rx_queue area, but seems like worst > case that bpf_xdp_get_hwtstamp can probably receive a xdp_md ctx and > parse it out from the pre-populated metadata? I'd think so, worst case the driver can put xdp_md into a struct and container_of() to get to its own stack with whatever fields it needs. > Btw, do we also need to think about the redirect case? What happens > when I redirect one frame from a device A with one metadata format to > a device B with another? If there is a program on Tx then it'd be trivial - just do the info <-> descriptor translation in the opposite direction than Rx. TBH I'm not sure how it'd be done in the current approach, either. Now I questioned the BTF way and mentioned the Tx-side program in a single thread, I better stop talking...