From: Yonghong Song <yonghong.song@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
Amery Hung <ameryhung@gmail.com>
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Fix xdp_pull_data failure with 64K page
Date: Thu, 22 Jan 2026 07:31:57 -0800 [thread overview]
Message-ID: <342128a1-30e5-403e-abbe-0d49f76765db@linux.dev> (raw)
In-Reply-To: <45c5425c-351c-4db4-b069-9ba0a03a7021@oracle.com>
On 1/22/26 3:02 AM, Alan Maguire wrote:
> On 20/01/2026 21:09, Yonghong Song wrote:
>> If the argument 'pull_len' of run_test() is 'PULL_MAX' or
>> 'PULL_MAX | PULL_PLUS_ONE', the eventual pull_len size
>> will close to the page size. On arm64 systems with 64K pages,
>> the pull_len size will be close to 64K. But the existing buffer
>> will be close to 9000 which is not enough to pull.
>>
>> So for 64K page size and selective run_tests(), increase
>> buff size from 9000 to 90000 to ensure enough buffer space
>> to pull.
>>
>> Cc: Amery Hung <ameryhung@gmail.com>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> Tested-by: Alan Maguire <alan.maguire@oracle.com>
>
> one optional suggestion below..
>
>
>> ---
>> .../selftests/bpf/prog_tests/xdp_pull_data.c | 16 +++++++++++-----
>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_pull_data.c b/tools/testing/selftests/bpf/prog_tests/xdp_pull_data.c
>> index efa350d04ec5..32ac99406d28 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/xdp_pull_data.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_pull_data.c
>> @@ -8,6 +8,7 @@
>> #define PULL_PLUS_ONE (1 << 30)
>>
>> #define XDP_PACKET_HEADROOM 256
>> +#define PAGE_SIZE_64K 65536
>>
>> /* Find headroom and tailroom occupied by struct xdp_frame and struct
>> * skb_shared_info so that we can calculate the maximum pull lengths for
>> @@ -114,12 +115,17 @@ static void test_xdp_pull_data_basic(void)
>> {
>> u32 pg_sz, max_meta_len, max_data_len;
>> struct test_xdp_pull_data *skel;
>> + int buff_len;
>>
>> skel = test_xdp_pull_data__open_and_load();
>> if (!ASSERT_OK_PTR(skel, "test_xdp_pull_data__open_and_load"))
>> return;
>>
>> pg_sz = sysconf(_SC_PAGE_SIZE);
>> + if (pg_sz == PAGE_SIZE_64K)
>> + buff_len = 90000;
>> + else
>> + buff_len = 9000;
>>
> nit: should we generalize here and just use 1.5 * pg_sz; i.e.
>
> buff_len = pg_sz + (pg_sz/2);
>
> that would eliminate the need for the 64k page size #define.
Thanks for suggestion! This indeed simpler. Will make the change in v2.
>
>> if (find_xdp_sizes(skel, pg_sz))
>> goto out;
>> @@ -140,13 +146,13 @@ static void test_xdp_pull_data_basic(void)
>> run_test(skel, XDP_PASS, pg_sz, 9000, 0, 1025, 1025);
>>
>> /* multi-buf pkt, empty linear data area, pull requires memmove */
>> - run_test(skel, XDP_PASS, pg_sz, 9000, 0, 0, PULL_MAX);
>> + run_test(skel, XDP_PASS, pg_sz, buff_len, 0, 0, PULL_MAX);
>>
>> /* multi-buf pkt, no headroom */
>> - run_test(skel, XDP_PASS, pg_sz, 9000, max_meta_len, 1024, PULL_MAX);
>> + run_test(skel, XDP_PASS, pg_sz, buff_len, max_meta_len, 1024, PULL_MAX);
>>
>> /* multi-buf pkt, no tailroom, pull requires memmove */
>> - run_test(skel, XDP_PASS, pg_sz, 9000, 0, max_data_len, PULL_MAX);
>> + run_test(skel, XDP_PASS, pg_sz, buff_len, 0, max_data_len, PULL_MAX);
>>
>> /* Test cases with invalid pull length */
>>
>> @@ -154,7 +160,7 @@ static void test_xdp_pull_data_basic(void)
>> run_test(skel, XDP_DROP, pg_sz, 2048, 0, 2048, 2049);
>>
>> /* multi-buf pkt with no space left in linear data area */
>> - run_test(skel, XDP_DROP, pg_sz, 9000, max_meta_len, max_data_len,
>> + run_test(skel, XDP_DROP, pg_sz, buff_len, max_meta_len, max_data_len,
>> PULL_MAX | PULL_PLUS_ONE);
>>
>> /* multi-buf pkt, empty linear data area */
>> @@ -165,7 +171,7 @@ static void test_xdp_pull_data_basic(void)
>> PULL_MAX | PULL_PLUS_ONE);
>>
>> /* multi-buf pkt, no tailroom */
>> - run_test(skel, XDP_DROP, pg_sz, 9000, 0, max_data_len,
>> + run_test(skel, XDP_DROP, pg_sz, buff_len, 0, max_data_len,
>> PULL_MAX | PULL_PLUS_ONE);
>>
>> out:
next prev parent reply other threads:[~2026-01-22 15:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 21:09 [PATCH bpf-next 1/2] selftests/bpf: Fix task_local_data failure with 64K page Yonghong Song
2026-01-20 21:09 ` [PATCH bpf-next 2/2] selftests/bpf: Fix xdp_pull_data " Yonghong Song
2026-01-22 11:02 ` Alan Maguire
2026-01-22 15:31 ` Yonghong Song [this message]
2026-01-22 8:00 ` [PATCH bpf-next 1/2] selftests/bpf: Fix task_local_data " Alan Maguire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=342128a1-30e5-403e-abbe-0d49f76765db@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox