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 164999CFC71 for ; Wed, 14 Dec 2022 19:43: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=gUPlgfZn Received: by mail-pj1-x1033.google.com with SMTP id u15-20020a17090a3fcf00b002191825cf02so112602pjm.2 for ; Wed, 14 Dec 2022 10:43: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=11gnFBq5/B+6biAVW8qF16RNrVbsfKYnaU/ZjQVxwSg=; b=gUPlgfZnJpd00o4gzd7LSKqLT48FfcnBbc/M6xdwTdHKeeGLYveYNUvJCR22pieC83 3vq7BS6ZZmkGT7DoTucMHo4jst548PqaCTvKBes56fqboWoU+ydn15qfpl1M0w7E5Pbh NfJFhxaMCm0WUNsZvrU/rcesWVahdyiwNedMvl09dY42Uarhs9hqSptDFaxlwYOpneEq YCQ2tCdl2ysTA0wSj1gN3is0HR27fS+l+PovZWo70RK8NFe0QjECNSYtPH7jHgPyD4SQ QpVS6uekED33vl18nVJ03Jimm+iWbvOYYWnOoCgu6WPotn9MdXj60SSD3Vu8yxVf6+us IDIg== 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=11gnFBq5/B+6biAVW8qF16RNrVbsfKYnaU/ZjQVxwSg=; b=ySjyDXze/ccQsQ6ErWGFhVenYP1V8tgoblIvc6fG5YlOi3gK/gSAKVPZrqPfPKmZyK YgRUTTA5u3vLnTAgRBKNvznInONH9d4NMAK9h3bJjJ8fVL4OeDOQvUhgIDExSDLWjDeI s2iFESeE4vGO4GNL+yKyH/b87nDa6U7EnjpOVTuG2PKML20tDuLWyQq6bfYcxv3IRAf7 UBvzFYtZryZmH+idC76AciRPKidjExQNhpr5T99xeUsU4pKmc2F7j0ChljuVuAw5+7Oc y+Tp676c1hcLFhIf0K24XCzkNDb81r/11Xp8D/CqMfnpKOOL3eqBz5IjJ3pecM51ZQSm ZCXA== X-Gm-Message-State: AFqh2kpReDyDJuSLG8xX3ye/+BdwAyv2h+SclmTjaXj1V0qXvTGNl6Q/ MkVdgE6rJSqA6rETa8YAbRRWBXRlTJGTOP+LmjsV/g== X-Google-Smtp-Source: AMrXdXuJdZAKGvf4ZH96xVGYPU6uFwCC+7t6sVlZeIeSR0k+n4pnYJV3tA4TG8LYfPQawp8d6x7R0rhg7mkCT8xQv7c= X-Received: by 2002:a17:90a:1f82:b0:21e:df53:9183 with SMTP id x2-20020a17090a1f8200b0021edf539183mr385673pja.66.1671043388240; Wed, 14 Dec 2022 10:43:08 -0800 (PST) MIME-Version: 1.0 References: <20221213023605.737383-1-sdf@google.com> <20221213023605.737383-2-sdf@google.com> <87fsdigtow.fsf@toke.dk> In-Reply-To: <87fsdigtow.fsf@toke.dk> From: Stanislav Fomichev Date: Wed, 14 Dec 2022 10:42:56 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: D6V6RCSHIBSJWP7H7MR6QSOZRQM5TBA3 X-Message-ID-Hash: D6V6RCSHIBSJWP7H7MR6QSOZRQM5TBA3 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: David Vernet , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, 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 X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v4 01/15] bpf: Document 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, Dec 14, 2022 at 2:34 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Stanislav Fomichev writes: > > > On Tue, Dec 13, 2022 at 8:37 AM David Vernet wrote= : > >> > >> On Mon, Dec 12, 2022 at 06:35:51PM -0800, Stanislav Fomichev wrote: > >> > Document all current use-cases and assumptions. > >> > > >> > 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: xdp-hints@xdp-project.net > >> > Cc: netdev@vger.kernel.org > >> > Signed-off-by: Stanislav Fomichev > >> > --- > >> > Documentation/bpf/xdp-rx-metadata.rst | 90 ++++++++++++++++++++++++= +++ > >> > 1 file changed, 90 insertions(+) > >> > create mode 100644 Documentation/bpf/xdp-rx-metadata.rst > >> > > >> > diff --git a/Documentation/bpf/xdp-rx-metadata.rst b/Documentation/b= pf/xdp-rx-metadata.rst > >> > new file mode 100644 > >> > index 000000000000..498eae718275 > >> > --- /dev/null > >> > +++ b/Documentation/bpf/xdp-rx-metadata.rst > >> > >> I think you need to add this to Documentation/bpf/index.rst. Or even > >> better, maybe it's time to add an xdp/ subdirectory and put all docs > >> there? Don't want to block your patchset from bikeshedding on this > >> point, so for now it's fine to just put it in > >> Documentation/bpf/index.rst until we figure that out. > > > > Maybe let's put it under Documentation/networking/xdp-rx-metadata.rst > > and reference form Documentation/networking/index.rst? Since it's more > > relevant to networking than the core bpf? > > > >> > @@ -0,0 +1,90 @@ > >> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > +XDP RX Metadata > >> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > + > >> > +XDP programs support creating and passing custom metadata via > >> > +``bpf_xdp_adjust_meta``. This metadata can be consumed by the follo= wing > >> > +entities: > >> > >> Can you add a couple of sentences to this intro section that explains > >> what metadata is at a high level? > > > > I'm gonna copy-paste here what I'm adding, feel free to reply back if > > still unclear. (so we don't have to wait another week to discuss the > > changes) > > > > XDP programs support creating and passing custom metadata via > > ``bpf_xdp_adjust_meta``. The metadata can contain some extra informatio= n > > about the packet: timestamps, hash, vlan and tunneling information, etc= . > > This metadata can be consumed by the following entities: > > This is not really accurate, though? The metadata area itself can > contain whatever the XDP program wants it to, and I think you're > conflating the "old" usage for arbitrary storage with the driver-kfunc > metadata support. > > I think we should clear separate the two: the metadata area is just a > place to store data (and is not consumed by the stack, except that > TC-BPF programs can access it), and the driver kfuncs are just a general > way to get data out of the drivers (and has nothing to do with the > metadata area, you can just get the data into stack variables). > > While it would be good to have a documentation of the general metadata > area stuff somewhere, I don't think it necessarily have to be part of > this series, so maybe just stick to documenting the kfuncs? Maybe I can reword to something like below? The metadata can be used to store some extra information about the packet timestamps, hash, vlan and tunneling information, etc. This way we are not actually defining what it is, but hinting about how it's commonly used? > -Toke >