From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mail.toke.dk (Postfix) with ESMTPS id A77869C5426 for ; Wed, 23 Nov 2022 23:29:41 +0100 (CET) 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=DmmnChB6 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 ams.source.kernel.org (Postfix) with ESMTPS id 8E525B82542; Wed, 23 Nov 2022 22:29:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CA3CC433D6; Wed, 23 Nov 2022 22:29:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669242579; bh=cH9nHeYLvsFLUPXg0Ojh1J6f4FowOk1ddzAiez/0fDM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DmmnChB6g81EqGDriHV4aoCQ98VlVoIyVw9WUJE0KSHyH2uQRT1uUnKrsjl8z+g/e 3itadwVQd4oV/FiGdXsZjeqkhEQVP7YkHCMqEuvgh1nIxyjRYB/Aic1+CdM83fIG5G HTX+q1LxQi7wB6oX+88lc4xbJIqoYERcM5fG3XBF9+fu0M5kUM6RRl3AoywkcrzBiD fqK3yrhTZabXDccfal9ZnKmU52MpUESfuZzUdj4V1ojw45tysRMymsCzgfdATM88Vb oGCofBXA0kVpQMxLaGms7UkiIYY48yT1RZzOBhMcqLwFpobyby3n6l1HHJbKe8aMDV gXd/kGhtV6cpQ== Date: Wed, 23 Nov 2022 14:29:37 -0800 From: Saeed Mahameed To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Message-ID: References: <20221121182552.2152891-1-sdf@google.com> <20221123144641.339138-1-toke@redhat.com> <20221123144641.339138-2-toke@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20221123144641.339138-2-toke@redhat.com> Message-ID-Hash: OS55NXNQXHFWKGPDH67JQRWATBL6MVZR X-Message-ID-Hash: OS55NXNQXHFWKGPDH67JQRWATBL6MVZR X-MailFrom: saeed@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: bpf@vger.kernel.org, John Fastabend , David Ahern , Martin KaFai Lau , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , Stanislav Fomichev , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next 2/2] mlx5: Support XDP RX metadata List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 23 Nov 15:46, Toke H=F8iland-J=F8rgensen wrote: >Support RX hash and timestamp metadata kfuncs. We need to pass in the cqe >pointer to the mlx5e_skb_from* functions so it can be retrieved from the >XDP ctx to do this. > >Cc: John Fastabend >Cc: David Ahern >Cc: Martin KaFai Lau >Cc: Jakub Kicinski >Cc: Willem de Bruijn >Cc: Jesper Dangaard Brouer >Cc: Anatoly Burakov >Cc: Alexander Lobakin >Cc: Magnus Karlsson >Cc: Maryam Tahhan >Cc: Stanislav Fomichev >Cc: xdp-hints@xdp-project.net >Cc: netdev@vger.kernel.org >Signed-off-by: Toke H=F8iland-J=F8rgensen >--- >This goes on top of Stanislav's series, obvioulsy. Verified that it works = using >the xdp_hw_metadata utility; going to do ome benchmarking and follow up wi= th the >results, but figured I'd send this out straight away in case others wanted= to >play with it. > >Stanislav, feel free to fold it into the next version of your series if you >want! > [...] > #endif /* __MLX5_EN_XSK_RX_H__ */ >diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/n= et/ethernet/mellanox/mlx5/core/en_main.c >index 14bd86e368d5..015bfe891458 100644 >--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >@@ -4890,6 +4890,10 @@ const struct net_device_ops mlx5e_netdev_ops =3D { > .ndo_tx_timeout =3D mlx5e_tx_timeout, > .ndo_bpf =3D mlx5e_xdp, > .ndo_xdp_xmit =3D mlx5e_xdp_xmit, >+ .ndo_xdp_rx_timestamp_supported =3D mlx5e_xdp_rx_timestamp_supported, >+ .ndo_xdp_rx_timestamp =3D mlx5e_xdp_rx_timestamp, >+ .ndo_xdp_rx_hash_supported =3D mlx5e_xdp_rx_hash_supported, >+ .ndo_xdp_rx_hash =3D mlx5e_xdp_rx_hash, I hope i am not late to the party. but I already expressed my feelings regarding using kfunc for xdp hints, @LPC and @netdevconf. I think it's wrong to use indirect calls, and for many usecases the overhead will be higher than just calculating the metadata on the spot. so you will need two indirect calls per packet per hint..=20 some would argue on some systems calculating the hash would be much faster. and one major reason to have the hints is to accelerate xdp edge and security programs with the hw provided hints. what happened with just asking the driver to place the data in a specific location on the headroom?=20