From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 04F1643341 for ; Thu, 16 Nov 2023 09:11:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD995402D2; Thu, 16 Nov 2023 09:11:40 +0100 (CET) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mails.dpdk.org (Postfix) with ESMTP id 994484027D for ; Thu, 16 Nov 2023 09:11:39 +0100 (CET) Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6ce353df504so257777a34.3 for ; Thu, 16 Nov 2023 00:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700122299; x=1700727099; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6yAbnEiXUblddxQRUOAhVkOk7+EWTlZbi4xsZi433uE=; b=X08CButy3bSmelA8p5p4kknJkNemOaxRctGW6Q3EAKfKeaFL7xPTlJqXyFiBWXZgOO 3tPA+ofOTNQMuFwPJ0IBPGEkTAX0X3DscTzLi3vEk8z4h3iOiX6UblV4wQGiiWmnH0kj uZTGXLCfcr/T88wsWVjQfOXG6nAdN59n5krPCiHsXvMmY3WSV/Rfb4OI6uuO7WWq7Xhs FaxLBkFH7ofjNwz1+yhfG+oQzg3PSPNWRddn3fbXyQhZUiOsqDbNrosmn7lgEbQci6XM Ar2OxyrNepzoSAOwPJhcL5bwsqG8Ozgr9fik+mkFmY+YPvDJFiAw6rFgYOxCNmMvpbyl Cxww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700122299; x=1700727099; h=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=6yAbnEiXUblddxQRUOAhVkOk7+EWTlZbi4xsZi433uE=; b=WxNHigaMEU4Z2wHEUDZvpgZJiVS9fhzao0+kXCKLCltmeIO3GxI4Qna3OQGemYyFqT hx0/MzmTLtpW18JJhGfOx8+Uv0WFgmZTeegAuzjhgq79UU8HH5a90Wa4ZEBDv6ioqUC/ BGZd0A7aqlnqyAZohTRVelLm6oTwa+bfEOlK5abU4eM9g7wQ0DGnLNHvZzzLH3nLIHtf k6u14RnbYX9mkKii7EZeM9STjOj+LaFzli98MBFVupmvu6WxSTZ98UEN/IJAPWrvIBma 2fWcmHwIg9gylyBfiHAXAWOkheMDmK/h3Bu84dMJo+QAsHON7eaI36gcW/6dG+UKfNdj ZnUw== X-Gm-Message-State: AOJu0YwRk0LHBKuy64NgDr2jwXzfcuHWOHX6fHHgy8Yrsv834HetXIT1 SXlUPL7cMnqZDFnBrwCzmXN68S0gjrewFP4hjWGKJvYVBCo= X-Google-Smtp-Source: AGHT+IHS8m9g4trTUBzGILuN5YHYeEnl0R55Lgyznm+V5eCaEZC1CdVEh0b5vkHboM6gistT7+Yk2x0PKyK8T+8tFyQ= X-Received: by 2002:a9d:6543:0:b0:6b9:9cc0:537f with SMTP id q3-20020a9d6543000000b006b99cc0537fmr7800459otl.33.1700122298655; Thu, 16 Nov 2023 00:11:38 -0800 (PST) MIME-Version: 1.0 References: <20231115071923.6c550190@hermes.local> In-Reply-To: <20231115071923.6c550190@hermes.local> From: madhukar mythri Date: Thu, 16 Nov 2023 13:41:27 +0530 Message-ID: Subject: Re: Failed to load eBPF byte-code on TAP device To: Stephen Hemminger Cc: users Content-Type: multipart/alternative; boundary="000000000000afaa60060a409122" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000afaa60060a409122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, I had added some logs in the BPF verifier of Kernel code, to print the number of instructions processed and error-code returned as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D logs # dmesg |tail -n 20 [ 76.318101] #### do_check: instructions Processed 999989 insn [ 76.318102] #### do_check: instructions Processed 999990 insn [ 76.318103] #### do_check: instructions Processed 999991 insn [ 76.318104] #### do_check: instructions Processed 999992 insn [ 76.318105] #### do_check: instructions Processed 999993 insn [ 76.318106] #### do_check: instructions Processed 999994 insn [ 76.318107] #### do_check: instructions Processed 999995 insn [ 76.318108] #### do_check: instructions Processed 999996 insn [ 76.318109] #### do_check: instructions Processed 999997 insn [ 76.318110] #### do_check: instructions Processed 999998 insn [ 76.318111] #### do_check: instructions Processed 999999 insn [ 76.318112] #### do_check: instructions Processed 1000000 insn [ 76.318113] BPF program is too large. Processed 1000001 insn [ 76.318209] ########## bpf_check: do_check_main done..: ret: -7 [ 76.318210] ########## bpf_check: bpf_prog_offload_finalize done..: ret: -7 [ 76.318212] ########## bpf_check: check_max_stack_depth done..: ret: -7 [ 76.318212] ########## bpf_check: fixup_call_args done..: ret: -7 [ 76.318224] ########## bpf_check: end..: ret: -7 [ 76.318224] ########## BPF bpf_check return err: -7..: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Only these logs which I add in the Kernel-code were printed and do not see any other Kernel-logs. Thanks, Madhuker. On Wed, Nov 15, 2023 at 8:49=E2=80=AFPM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Wed, 15 Nov 2023 15:38:55 +0530 > madhukar mythri wrote: > > > Hi all, > > > > On the RHEL9.2 with DPDK 22.11.1 version, DPDK primary application fail= ed > > to add RSS flow on TAP sub-device, when loading the TAP BPF byte-code > > instructions. > > > > This "struct bpf_insn l3_l4_hash_insns[]" array(from file: > > drivers/net/tap/tap_bpf_insns.h) is in eBPF bytecode instructions forma= t, > > this eBPF failed to load on TAP PMD with the following error: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > rss_add_actions(): Failed to load BPF section 'l3_l4' (7): Argument lis= t > > too long. > > net_failsafe: Failed to create a flow on sub_device 1." > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Kernel-version: 5.15.0 #9 SMP PREEMPT > > Arch: x86_64 GNU/Linux > > > > When added some debug logs on Kernel BPF verifier code, we could see th= at > > instruction processed were reached to 1 Million. > > But, the Byte code has only 1698 instructions only. Why the Kernel BPF > > verifier is processing beyond 1,698 instructions ? > > > > The same byte-code(with DPDK-22.11.1) worked well with RHEL8.x and not > > working in RHEL-9.x version. > > > > Does anybody faced such issues ? > > Please let me know how to debug such issues on Byte-code. > > > > Thanks, > > Madhukar. > > Is there anything in the kernel log? > > > --000000000000afaa60060a409122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Stephen,

I had added some logs = in the BPF verifier of Kernel code, to print the number of instructions=C2= =A0processed and error-code returned as follows:
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
logs # dmesg |tail -n 20
[ =C2=A0 76.318101] #### do_check: instruc= tions Processed 999989 insn
[ =C2=A0 76.318102] #### do_check: instructi= ons Processed 999990 insn
[ =C2=A0 76.318103] #### do_check: instruction= s Processed 999991 insn
[ =C2=A0 76.318104] #### do_check: instructions = Processed 999992 insn
[ =C2=A0 76.318105] #### do_check: instructions Pr= ocessed 999993 insn
[ =C2=A0 76.318106] #### do_check: instructions Proc= essed 999994 insn
[ =C2=A0 76.318107] #### do_check: instructions Proces= sed 999995 insn
[ =C2=A0 76.318108] #### do_check: instructions Processe= d 999996 insn
[ =C2=A0 76.318109] #### do_check: instructions Processed = 999997 insn
[ =C2=A0 76.318110] #### do_check: instructions Processed 99= 9998 insn
[ =C2=A0 76.318111] #### do_check: instructions Processed 9999= 99 insn
[ =C2=A0 76.318112] #### do_check: instructions Processed 100000= 0 insn
[ =C2=A0 76.318113] BPF program is too large. Processed 1000001 i= nsn
[ =C2=A0 76.318209] ########## bpf_check: =C2=A0do_check_main done..= : ret: -7
[ =C2=A0 76.318210] ########## bpf_check: =C2=A0bpf_prog_offl= oad_finalize done..: ret: -7
[ =C2=A0 76.318212] ########## bpf_check: = =C2=A0check_max_stack_depth done..: ret: -7
[ =C2=A0 76.318212] #######= ### bpf_check: =C2=A0fixup_call_args done..: ret: -7
[ =C2=A0 76.318224= ] ########## bpf_check: =C2=A0end..: ret: -7
[ =C2=A0 76.318224] ######= #### =C2=A0BPF =C2=A0bpf_check return err: -7..:
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= br>
Only these logs which I add in the Kernel-code were printed a= nd do not see any other Kernel-logs.

Thanks,
=
Madhuker.

On Wed, Nov 15, 2023 at 8:49=E2=80=AFPM Stephen Hemming= er <stephen@networkplumber= .org> wrote:
On Wed, 15 Nov 2023 15:38:55 +0530
madhukar mythri <madhukar.mythri@gmail.com> wrote:

> Hi all,
>
> On the RHEL9.2 with DPDK 22.11.1 version, DPDK primary application fai= led
> to add RSS flow on TAP sub-device, when loading the TAP BPF byte-code<= br> > instructions.
>
> This "struct bpf_insn l3_l4_hash_insns[]" array(from file: > drivers/net/tap/tap_bpf_insns.h) is in eBPF bytecode instructions form= at,
> this eBPF failed to load on TAP PMD with the following error:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> rss_add_actions(): Failed to load BPF section 'l3_l4' (7): Arg= ument list
> too long.
> net_failsafe: Failed to create a flow on sub_device 1."
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> On Kernel-version:=C2=A0 5.15.0 #9 SMP PREEMPT
> Arch: x86_64 GNU/Linux
>
> When added some debug logs on Kernel BPF verifier code, we could see t= hat
> instruction processed were reached to 1 Million.
> But, the Byte code has only 1698 instructions only. Why the Kernel BPF=
> verifier is processing beyond 1,698 instructions ?
>
> The same byte-code(with DPDK-22.11.1) worked well with RHEL8.x and not=
> working in RHEL-9.x version.
>
> Does anybody faced such issues ?
> Please let me know how to debug such issues on Byte-code.
>
> Thanks,
> Madhukar.

Is there anything in the kernel log?


--000000000000afaa60060a409122--