From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by mail.toke.dk (Postfix) with ESMTPS id 92FDD9B85CE for ; Thu, 10 Nov 2022 02:26:13 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=qrxtzVcL Received: by mail-pj1-x1033.google.com with SMTP id d13-20020a17090a3b0d00b00213519dfe4aso371379pjc.2 for ; Wed, 09 Nov 2022 17:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=QDNKEh/nnMeolmM2NRHpBe+qACbk9dXcfRIfhAI2nC4=; b=qrxtzVcLdOjnF1pVDiyeQcnoJ2J8SBIp14Y38ivJX3x/WhZhPe2HQWipf+K/U77yA0 emgCx8WohDOumt2OnN02MFX7SEF4rtKb2vPX+EwXDPLkdR/NRQaELEn0eW0cDzv3HbU/ 1+dlHps5usVtChYEW1Z0L8hsbzNHnUJMNKq+fXta1fwfx8FyV00sDC18oW+LPGhIb49N WYwPErYLOOViLp8m/nJ4m9rh4t5FY1hzUmbd2Z1H0AxJroIqnIBs6W9OtHAxHGj9O3qM pll6Vbthi8kV7N4853ayKZoFv8e4iQae07YtCte+89y84ylIIT71Y1IZP0gQgCXDUpCJ oq8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=QDNKEh/nnMeolmM2NRHpBe+qACbk9dXcfRIfhAI2nC4=; b=lJoKqimPI1zuyNLxltMhFDxWJxJDgp1EbOg5zf9DX7hutaKI+zEoZ2KhPw6xV/sxOh 0CIqKgTj59xRNwjC1ArJSLTiGdZ2OblecLwWfnZgbsTKJ87rxDLVTrP/d9DIgTjm5VYf L1zzbe7mtmQbF2HjFXhBWJc1V8DBEGU8CmG2EUp1ppTfdkISf4WqtZ7J3wz/gS/nNh4S GHB6ugzF51tskK4TShP84h6JDKazUAjPv8scfs/DYJORL0XbKf8JOhTgc9g0I5iHsXAH 28AnI2sd6qTT7aI55NBtBnaiL2rjyUFPlFaOuS7pjXkpv7JDE/tYa5xGL2wojiciNNEb yszA== X-Gm-Message-State: ACrzQf3Uf/X+bVVmvXNepJIJ51TFOt8Y4+4nO2Q3m4e4hmfSWBel3IrI liexFY7EqDXJS9y9f5nOc8I= X-Google-Smtp-Source: AMsMyM7S9Svs1nfnHtDkykC5jm6zIG/MFVAfwMkeX9pyECGdstQcsq/gvvpf8yDb9Z+5A3MiyJoaGg== X-Received: by 2002:a17:902:bcc1:b0:187:31da:494a with SMTP id o1-20020a170902bcc100b0018731da494amr48297993pls.121.1668043572087; Wed, 09 Nov 2022 17:26:12 -0800 (PST) Received: from localhost ([98.97.44.95]) by smtp.gmail.com with ESMTPSA id j126-20020a625584000000b0056bb21cd7basm8876013pfb.51.2022.11.09.17.26.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Nov 2022 17:26:11 -0800 (PST) Date: Wed, 09 Nov 2022 17:26:10 -0800 From: John Fastabend To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Martin KaFai Lau , Stanislav Fomichev Message-ID: <636c533231572_13c9f42087c@john.notmuch> In-Reply-To: <87leokz8lq.fsf@toke.dk> References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-7-sdf@google.com> <187e89c3-d7de-7bec-c72e-d9d6eb5bcca0@linux.dev> <9a8fefe4-2fcb-95b7-cda0-06509feee78e@linux.dev> <6f57370f-7ec3-07dd-54df-04423cab6d1f@linux.dev> <87leokz8lq.fsf@toke.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: PLVKCH4COM3GKBNASSF3TE4KKKU4IDVG X-Message-ID-Hash: PLVKCH4COM3GKBNASSF3TE4KKKU4IDVG X-MailFrom: john.fastabend@gmail.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: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , 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, bpf@vger.kernel.org X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 06/14] xdp: Carry over xdp metadata into skb context List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Snipping a bit of context to reply to this bit: > = > >>>> Can the xdp prog still change the metadata through xdp->data_meta?= tbh, I am not > >>>> sure it is solid enough by asking the xdp prog not to use the same= random number > >>>> in its own metadata + not to change the metadata through xdp->data= _meta after > >>>> calling bpf_xdp_metadata_export_to_skb(). > >>> > >>> What do you think the usecase here might be? Or are you suggesting = we > >>> reject further access to data_meta after > >>> bpf_xdp_metadata_export_to_skb somehow? > >>> > >>> If we want to let the programs override some of this > >>> bpf_xdp_metadata_export_to_skb() metadata, it feels like we can add= > >>> more kfuncs instead of exposing the layout? > >>> > >>> bpf_xdp_metadata_export_to_skb(ctx); > >>> bpf_xdp_metadata_export_skb_hash(ctx, 1234); > = Hi Toke, Trying not to bifurcate your thread. Can I start a new one here to elaborate on these use cases. I'm still a bit lost on any use case for this that makes sense to actually deploy on a network. > There are several use cases for needing to access the metadata after > calling bpf_xdp_metdata_export_to_skb(): > = > - Accessing the metadata after redirect (in a cpumap or devmap program,= > or on a veth device) I think for devmap there are still lots of opens how/where the skb is even built. For cpumap I'm a bit unsure what the use case is. For ice, mlx and such you should use the hardware RSS if performance is top of mind. And then for specific devices on cpumap (maybe realtime or ptp things?) could we just throw it through the xdp_frame? > - Transferring the packet+metadata to AF_XDP In this case we have the metadata and AF_XDP program and XDP program simply need to agree on metadata format. No need to have some magic numbers and driver specific kfuncs. > - Returning XDP_PASS, but accessing some of the metadata first (whether= > to read or change it) > = I don't get this case? XDP_PASS should go to stack normally through drivers build_skb routines. These will populate timestamp normally. My guess is simply descriptor->skb load/store is cheaper than carrying around this metadata and doing the call in BPF side. Anyways you just built an entire skb and hit the stack I don't think you will notice this noise in any benchmark.=