From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530])
	by mail.toke.dk (Postfix) with ESMTPS id 197B6A1595D
	for <xdp-hints@xdp-project.net>; Mon,  3 Jul 2023 23:06:50 +0200 (CEST)
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=20221208 header.b=jrrCeScL
Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-55b22f82ac8so2864118a12.1
        for <xdp-hints@xdp-project.net>; Mon, 03 Jul 2023 14:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20221208; t=1688418408; x=1691010408;
        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=0s37NzTHMUBaqLFmLcuPGyHFd30//csXthbXBR4ahCA=;
        b=jrrCeScL4kYlEtkq3xekVTO6oZ+0cPyT6bqmExqbVucAP4WHz/eAFck7ntHOrVZvnI
         RfHU2A12F0LjJvEqyGXtbYw+I4zqcFu7uSQ61gIsqMsx+9Xreqb6LVhR3XuYMTjJoKwJ
         caAoK9T3CtgD2thvP/4ttX6ZMq6D4VVGWNhLO8MhpAkdJ6/ZEnm0U3HjYOif+nRBHj2B
         n/vPWyAq/Irxzk2cP1JYYilGgD3hQBKdGo2EqEg7WNulkg57Q2iJzpWiMT9UptW2LP5T
         R+vyHC8qeSlyZPIbjjzjuBOVmeSIT2ujSI48UIPO9lYSHFHYU5/OZiO44SQt9ngCXKpk
         LQ1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1688418408; x=1691010408;
        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=0s37NzTHMUBaqLFmLcuPGyHFd30//csXthbXBR4ahCA=;
        b=PTukutSLZHFHbuegndxpodmVaWw1cifBnRjRFYJx8uuST1t6NF0H/iN3KtenJHSf7X
         z9C7lx0BFfxs13a8CGTE5BRm9AXjttQ2wZbL/VrtFfWr6XtlbVfx9TJ9fhePQW0zgw5E
         lREvZxXRpd7RcD2H5c93/THXc59MwUJ6XrZLTKd32ZUxfu39jUTow7WVXsff3F4W0Pxt
         B/6kEsvC0u8WcNb2AXpWyREV2CGVXLUMZgCHhmtwkwZw3UYQ+6TLAhW6xMhlUfoIimSC
         WcrkVkBF8mCubxovpIgbCnJPJmAXJZKpyXPhGhbc0/+xJUe2FeAaQS/Jrn493doHx7v0
         c0ig==
X-Gm-Message-State: AC+VfDxg9ugCiu4uMV+OEwuPAIIX+HmKijkqIU6wWEUAZ8YYm2lt4tZE
	3MRLFLiHjuYi8aBEU8QkUsc=
X-Google-Smtp-Source: ACHHUZ47oCDS/VawOuS05S/BzNAIqU7kzR5VjubUQNTZC6eVHkTjWUNkjY1bpISisIJKBK3hmgQWpA==
X-Received: by 2002:a05:6a20:54a8:b0:126:2bb7:d660 with SMTP id i40-20020a056a2054a800b001262bb7d660mr22649845pzk.7.1688418407947;
        Mon, 03 Jul 2023 14:06:47 -0700 (PDT)
Received: from localhost ([2605:59c8:148:ba10::41f])
        by smtp.gmail.com with ESMTPSA id q28-20020a635c1c000000b00548d361c137sm14962708pgb.61.2023.07.03.14.06.47
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 03 Jul 2023 14:06:47 -0700 (PDT)
Date: Mon, 03 Jul 2023 14:06:46 -0700
From: John Fastabend <john.fastabend@gmail.com>
To: Larysa Zaremba <larysa.zaremba@intel.com>,
 bpf@vger.kernel.org
Message-ID: <64a3386623163_65205208fe@john.notmuch>
In-Reply-To: <20230703181226.19380-16-larysa.zaremba@intel.com>
References: <20230703181226.19380-1-larysa.zaremba@intel.com>
 <20230703181226.19380-16-larysa.zaremba@intel.com>
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit
Message-ID-Hash: 6N3OLNZJMHEZGNOCZ7IHT2YNNIZTKTNC
X-Message-ID-Hash: 6N3OLNZJMHEZGNOCZ7IHT2YNNIZTKTNC
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: Larysa Zaremba <larysa.zaremba@intel.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, sdf@google.com, haoluo@google.com, jolsa@kernel.org, David Ahern <dsahern@gmail.com>, Jakub Kicinski <kuba@kernel.org>, Willem de Bruijn <willemb@google.com>, Jesper Dangaard Brouer <brouer@redhat.com>, Anatoly Burakov <anatoly.burakov@intel.com>, Alexander Lobakin <alexandr.lobakin@intel.com>, Magnus Karlsson <magnus.karlsson@gmail.com>, Maryam Tahhan <mtahhan@redhat.com>, xdp-hints@xdp-project.net, netdev@vger.kernel.org, Aleksander Lobakin <aleksander.lobakin@intel.com>
X-Mailman-Version: 3.3.8
Precedence: list
Subject: [xdp-hints] Re: [PATCH bpf-next v2 15/20] net, xdp: allow metadata > 32
List-Id: XDP hardware hints design discussion <xdp-hints.xdp-project.net>
Archived-At: <https://lists.xdp-project.net/xdp-hints/64a3386623163_65205208fe@john.notmuch/>
List-Archive: <https://lists.xdp-project.net/xdp-hints/>
List-Help: <mailto:xdp-hints-request@xdp-project.net?subject=help>
List-Owner: <mailto:xdp-hints-owner@xdp-project.net>
List-Post: <mailto:xdp-hints@xdp-project.net>
List-Subscribe: <mailto:xdp-hints-join@xdp-project.net>
List-Unsubscribe: <mailto:xdp-hints-leave@xdp-project.net>

Larysa Zaremba wrote:
> From: Aleksander Lobakin <aleksander.lobakin@intel.com>
> 
> When using XDP hints, metadata sometimes has to be much bigger
> than 32 bytes. Relax the restriction, allow metadata larger than 32 bytes
> and make __skb_metadata_differs() work with bigger lengths.
> 
> Now size of metadata is only limited by the fact it is stored as u8
> in skb_shared_info, so maximum possible value is 255. Other important
> conditions, such as having enough space for xdp_frame building, are already
> checked in bpf_xdp_adjust_meta().
> 
> The requirement of having its length aligned to 4 bytes is still
> valid.
> 
> Signed-off-by: Aleksander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
>  include/linux/skbuff.h | 13 ++++++++-----
>  include/net/xdp.h      |  7 ++++++-
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 91ed66952580..cd49cdd71019 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -4209,10 +4209,13 @@ static inline bool __skb_metadata_differs(const struct sk_buff *skb_a,
>  {
>  	const void *a = skb_metadata_end(skb_a);
>  	const void *b = skb_metadata_end(skb_b);
> -	/* Using more efficient varaiant than plain call to memcmp(). */
> -#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64

Why are we removing the ifdef here? Its adding a runtime 'if' when its not
necessary. I would keep the ifdef and simply add the default case
in the switch.