From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by mail.toke.dk (Postfix) with ESMTPS id 35BFCA120DF for ; Thu, 22 Jun 2023 19:55:21 +0200 (CEST) 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=20221208 header.b=nivLASTM Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-260a4020ebaso3400372a91.2 for ; Thu, 22 Jun 2023 10:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687456518; x=1690048518; 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=PKB3mRshSFmiO5X8mqfZaGcfAhkZf796XK49+KeA2nU=; b=nivLASTMpRo9d/C5fU3XT02fBFJtnMyhaVhTA12az8nfW0Kci8JI7GsMYwiT7aFrCG eHybnL8S/H57MRFUktTry87TMzQPNlnF2W0zAdq3t0rhIkQpo1NmPoDfEvNdF+3UVshT fuV1N8YtFS1mt6PCw47isfruWcAGY33DdBjFG1sOlgcDA2QBzqq4DHsVDcXZMZKZuirD uaD747fWPzyYvG80kZaPdmVkgSq6l3FcJxbjkq/9V0fPkWvQKCG+YNROpxDX2gqW6Jms jf080wzNs+La5akpx2/SR26z5zxAVktXdubWWvsbl4koSLgoclR8uc4E4AnHSOEPgW4N ITHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687456518; x=1690048518; 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=PKB3mRshSFmiO5X8mqfZaGcfAhkZf796XK49+KeA2nU=; b=JPEskuUyIOo9LKBn+siIBvTjeIhAXmfFhxl8RQ0QRu7h6K5vkfyOb5NfEKy48pliKu Z7/sWIr4SNH1chNzQdBInyBg7J/OoCx9SP/M7ahxGbOC0P1kagr+3RL7frHOBvU80gp2 mJIEHnZvK8ClTMAoGXhTogBoVWlq0FqcjmNsnnrr2J297M38iuUojOB6aqWC6xGMgrwG PdNPKGsz2/NW4m+XTwOXeMnX+nqiNxDwyD3iOeTIFcPxeF/et9yW6B5P0fCBNlKPr/qq h1HMCclHRYGaRk2Vmo2bAefOPXM91+2vv6MZZI08xH0OBWzBASy/KOK0kAr4NiDGExsm ffWg== X-Gm-Message-State: AC+VfDwBUok4LbUfmxGHNRZ4mgSbBj6u2XQFkWdMiIto6McpceW1zuPG HawvXXK/IQuz5aLmBGt/TobEAIbjgkhqUaiEOXSqxg== X-Google-Smtp-Source: ACHHUZ4TuFEAfOpGSTIkuuYTNosZ4GiLS4czTKFi2KQ1GHQT99Gl+2Ti2MPTwkGC0EMbHvrwDRfu5KIHymSiNHRSMUg= X-Received: by 2002:a17:90a:bc85:b0:260:9a19:5864 with SMTP id x5-20020a17090abc8500b002609a195864mr11786094pjr.1.1687456518292; Thu, 22 Jun 2023 10:55:18 -0700 (PDT) MIME-Version: 1.0 References: <20230621170244.1283336-1-sdf@google.com> <20230621170244.1283336-4-sdf@google.com> <57b9fc14-c02e-f0e5-148d-a549ebab6cf6@brouer.com> In-Reply-To: <57b9fc14-c02e-f0e5-148d-a549ebab6cf6@brouer.com> From: Stanislav Fomichev Date: Thu, 22 Jun 2023 10:55:06 -0700 Message-ID: To: "Jesper D. Brouer" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: K73G72KZJVTBHZVORT5KPYYCJVZRQ2HQ X-Message-ID-Hash: K73G72KZJVTBHZVORT5KPYYCJVZRQ2HQ 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: bpf@vger.kernel.org, brouer@redhat.com, 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, =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Karlsson, Magnus" , "xdp-hints@xdp-project.net" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 03/11] xsk: Support XDP_TX_METADATA_LEN List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Jun 22, 2023 at 2:11=E2=80=AFAM Jesper D. Brouer wrote: > > > This needs to be reviewed by AF_XDP maintainers Magnus and Bj=C3=B8rn (Cc= ) > > On 21/06/2023 19.02, Stanislav Fomichev wrote: > > For zerocopy mode, tx_desc->addr can point to the arbitrary offset > > and carry some TX metadata in the headroom. For copy mode, there > > is no way currently to populate skb metadata. > > > > Introduce new XDP_TX_METADATA_LEN that indicates how many bytes > > to treat as metadata. Metadata bytes come prior to tx_desc address > > (same as in RX case). > > From looking at the code, this introduces a socket option for this TX > metadata length (tx_metadata_len). > This implies the same fixed TX metadata size is used for all packets. > Maybe describe this in patch desc. I was planning to do a proper documentation page once we settle on all the details (similar to the one we have for rx). > What is the plan for dealing with cases that doesn't populate same/full > TX metadata size ? Do we need to support that? I was assuming that the TX layout would be fixed between the userspace and BPF. If every packet would have a different metadata length, it seems like a nightmare to parse?