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 D985543337 for ; Wed, 15 Nov 2023 11:09:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C2BA40285; Wed, 15 Nov 2023 11:09:09 +0100 (CET) Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) by mails.dpdk.org (Postfix) with ESMTP id A8B51400EF for ; Wed, 15 Nov 2023 11:09:07 +0100 (CET) Received: by mail-oo1-f53.google.com with SMTP id 006d021491bc7-5845213c583so3463675eaf.0 for ; Wed, 15 Nov 2023 02:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700042947; x=1700647747; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9Sjv+dX0rZCipLkBTQ4Qrp92aqOykyiwNpkn+5CfvJ0=; b=N0lgB+FGNpKx5Y3Nzp1W6/MIjVIid2N6taQgvU0+doytx+jb9anHKVC4whibYffcKr QKEogvNMfn2PcfPwaKSKRUnM79L32k4e2N2LcBqJebWXbczoa/WvKxH3M838cGtUpaLd widiJwSBanjrWseqMBj3RPgd2yob+vRb5iMqGri7ZRT0Sb2+qqoZn2YJigNuptCdly8H ehV8NEJxV3A43Vw2V7m9BNC3Kunfjiwg4hBKqdkB+qSlNFb9JumOyiRPDIQXiyS7qobp HMRKfwvvM6lSMx/FWcO5kqn6ElBtnc27mKKlHCS+yhBdtX8jMUglSu/A25iZtVY4VlVy YHTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700042947; x=1700647747; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9Sjv+dX0rZCipLkBTQ4Qrp92aqOykyiwNpkn+5CfvJ0=; b=nuJmTfNEsTnoVZsrUrMdqUdgY5CU84LToYlW8WX+RAQwr+UAwBlgmmRV4IOpfcVZP1 GlO1g0KWm+P4c1NVnu5bh9Ru4ycYgrXiXD4SHWNqQJgwFhTJe8ATKfpI6meSmwSKskMA WAWhZhI6QqvXTLyCHzlzVGQaV7mGlC9hz1qQsvFPTa0fZ85G0CrvOcrqh0D4WgxjhOZ3 JVOpVXJ0FWUx7bpGZ8pHWKGaTrSaUJ+g8vLaiyPKlDj/ErsBUMxMz+5VXlkbAWkFB5ex tPCAT5bMUl4b8gR3MM9+G2f5kS9QmfDCASElMJ4JPAFzpssbDaj/El7+JqptldTYQXd+ 8qSg== X-Gm-Message-State: AOJu0YxEKsevmOZlyqYA3Kkl/n08SP1dCm6Sg910l6M+K3YdKFZiOh5j McKLM8MNxCcn+fu9RpgbrrFE0kw8F+tXccPua03nwyRVzm0= X-Google-Smtp-Source: AGHT+IF+qONpJ/81GXrOvccnucapR4nPZMaOCO7rOw0gFcaNnxT+L+frwbb0bACC1+BvqOVxkSyNT3ki7JoVkf9jZKw= X-Received: by 2002:a05:6820:455:b0:58a:231d:750e with SMTP id p21-20020a056820045500b0058a231d750emr10973937oou.1.1700042946577; Wed, 15 Nov 2023 02:09:06 -0800 (PST) MIME-Version: 1.0 From: madhukar mythri Date: Wed, 15 Nov 2023 15:38:55 +0530 Message-ID: Subject: Failed to load eBPF byte-code on TAP device To: users Content-Type: multipart/alternative; boundary="000000000000ef0c3f060a2e174e" 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 --000000000000ef0c3f060a2e174e Content-Type: text/plain; charset="UTF-8" Hi all, On the RHEL9.2 with DPDK 22.11.1 version, DPDK primary application failed 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 format, this eBPF failed to load on TAP PMD with the following error: ===================== rss_add_actions(): Failed to load BPF section 'l3_l4' (7): Argument list too long. net_failsafe: Failed to create a flow on sub_device 1." ===================== 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 that 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. --000000000000ef0c3f060a2e174e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

On the RHEL9.2 with DPDK 22.11.= 1 version, DPDK primary application failed to add RSS flow on TAP sub-devic= e, when loading the TAP BPF byte-code instructions.

This "struc= t bpf_insn l3_l4_hash_insns[]" array(from file: drivers/net/tap/tap_bp= f_insns.h) is in eBPF bytecode instructions format, this eBPF failed to loa= d 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 B= PF section 'l3_l4' (7): Argument list too long.
net_failsafe: Fa= iled 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=A05.15.0 #9 = SMP PREEMPT
Arch: x86_64 GNU/Linux

When added some debug logs on = Kernel BPF verifier code, we could see that instruction processed were reac= hed to 1 Million.
But, the Byte code has only 1698 instructions only. Wh= y 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 work= ing in RHEL-9.x version.

Does anybody faced such issues ?
Please = let me know how to debug such issues on Byte-code.

Thanks,
Madhukar.
--000000000000ef0c3f060a2e174e--