From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by mail.toke.dk (Postfix) with ESMTPS id E56559C544B for ; Wed, 23 Nov 2022 23:45:10 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=piTIC4RW Received: by mail-oi1-x22e.google.com with SMTP id v81so20566124oie.5 for ; Wed, 23 Nov 2022 14:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sHBF341UB7UVlHmjLxw21h/DhRvlIsP/VwMIHyOu0Cw=; b=piTIC4RWLLhWFa20X04ciY3/ovKm6ZGqbrUhJVEYbjaGbJgL30zeNbSV1A2+3npDXf CxLYIAytQP1m9ZtVrPpjGncL7AFzlXGrjgvWUfIyTLAneMdpcjPbHXJqwkIBKuIQBYvW idSORnpLZ2hVXUYpHweQhTJf7X5v/rWMLKCDtUm4n4kvVFZ9cvdb4YOZ1F8pMMcF4BwJ EIkzITj3m1T7rmbDqhTFIX9HsJSBnAWEniPSIwcCdz4h6FyqqRvqxgAJQddufaplAGB6 yBcKhesbwFlmNrTy1MjUufzDup/IZ9OGL0gOzBs34hCSrGw/SQhLas4DRS/glVdiC/MW a05Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sHBF341UB7UVlHmjLxw21h/DhRvlIsP/VwMIHyOu0Cw=; b=anKdreEcmOrYUikib3/81ny3VTwnlOexFOpkZH68ONxvSVGFRsvEnQ8uxOH8zhE1v3 svKmj2aQ4nlBIisaUD0U/+ns9WvGrfNbY+m8Cquom2QMllm0IZ/oGiSJ4S4l+msv3NjC jmnP/EUA8IJ7OEvjMc+KZR1zd1aNg/UQjohWZPcitY6xO6QDykCQCnMlyH1ptd9M+Bz8 0B4IKO0L89uE9YzUDPs596/cHeKFVHeyEaIxF5XV5ctFXpGJdeNtye0A/wTDHi590aCK aJFVz7W1XtJqIkEDQwRPmriBm0hLCH9Jxw60FBdV3etBPYQOsfCRQuliz1JZRKv4zTHD Lz0g== X-Gm-Message-State: ANoB5pnYYqMLYLzrw+GQStmQgvpnZ5U+r7PbZjmIEdf4nSrwcLpDpnh2 9XGrBOw8gCnyNsl4pD/Yi56g+e/XsjrhMTVMFG+0/g== X-Google-Smtp-Source: AA0mqf7PGz+vykGSlqIhYyKX/n87PS0N5FoNzdp7q5bptfquGdsGcag2okw3SO4SmV5j2h56tDSb5HMZBiRV9jZpfmo= X-Received: by 2002:aca:674c:0:b0:35b:79ca:2990 with SMTP id b12-20020aca674c000000b0035b79ca2990mr2237880oiy.125.1669243509383; Wed, 23 Nov 2022 14:45:09 -0800 (PST) MIME-Version: 1.0 References: <20221121182552.2152891-1-sdf@google.com> <20221123144641.339138-1-toke@redhat.com> <20221123144641.339138-2-toke@redhat.com> In-Reply-To: From: Stanislav Fomichev Date: Wed, 23 Nov 2022 14:44:58 -0800 Message-ID: To: Saeed Mahameed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Z7GQV6Y36DHQ4O3A267TWAENABA6DOZO X-Message-ID-Hash: Z7GQV6Y36DHQ4O3A267TWAENABA6DOZO X-MailFrom: sdf@google.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: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , 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 , 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 Wed, Nov 23, 2022 at 2:29 PM Saeed Mahameed wrote: > > On 23 Nov 15:46, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >Support RX hash and timestamp metadata kfuncs. We need to pass in the cq= e > >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=C3=B8iland-J=C3=B8rgensen > >--- > >This goes on top of Stanislav's series, obvioulsy. Verified that it work= s using > >the xdp_hw_metadata utility; going to do ome benchmarking and follow up = with the > >results, but figured I'd send this out straight away in case others want= ed 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= /net/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_suppor= ted, > >+ .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.. > some would argue on some systems calculating the hash would be much faste= r. > 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? Take a look at [0], we are resolving indirect calls. We can also always go back to unrolling those calls as was done initially in [1]. 0: https://lore.kernel.org/bpf/20221121182552.2152891-3-sdf@google.com/ 1: https://lore.kernel.org/bpf/20221115030210.3159213-4-sdf@google.com/ kfunc approach seems more flexible than an all-or-nothing approach with the driver pre-filling all metadata.