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 C681544123 for ; Mon, 17 Jun 2024 23:40:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8E54840669; Mon, 17 Jun 2024 23:40:18 +0200 (CEST) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by mails.dpdk.org (Postfix) with ESMTP id C5AB84064E for ; Mon, 17 Jun 2024 23:40:16 +0200 (CEST) Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-6e4dbca52f0so3509613a12.0 for ; Mon, 17 Jun 2024 14:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718660416; x=1719265216; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=LHucmitdeenkyPDlHrAgq/RlVqg0kSVA0l3MjIdiySg=; b=3Cg81PJtDz5GrlrnFro96cYaDTlOKwlb+Dw3vGWg+JyAtfquzSXM3fzGOlz560/Fwu o3PmMuIBZHuJqXJb5Ry/lwC5OwYc3D4Kw/VG52Z4P50ZK+/+uH63viPdYq53Pmg6mc0d HZ/CTAQz5+x1kbYdUD76QPQfSKcKJTmsepYvqyRUINCHJMYvjG+MyP1ZiEF+E31A21za ytktv4LeTo8mUAa99xLNX5cE2eSnGeUcaObPwW0HefXRqFw14SHq3c8D5t/FB1hA7BGe p/pNp7RvHmFAT2NfFktIfMRY0nM6A1mB5z0HN2KSenCVG8lp6F0IHWs3TJg+GjOCGO2I lKUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718660416; x=1719265216; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LHucmitdeenkyPDlHrAgq/RlVqg0kSVA0l3MjIdiySg=; b=klo1F00JfiQtBy+sleeNAh0BrCLsvPE61iDuq+8ESSqDtiVOlZxxASsk4vb9Wt69QI rlGiciaQPrnIJa4t/rKVutBhiy1xJN3oaU5g37SgPIG/h/iviIDOQUoRRaRQYWYb6cjy KI5hAn+WCClg/1WxB3mw+ZiUsFKk6VKjgZa8PNAH24vcpKr4qgWce2EU8Fi7fSgCc10z qR7but93OEsnUZkZmuazZvuI6NG8rd8sK/jzc4MdQoYVIoHL30rI7CCu3C6nGgYOOBor GBIncT+x4ukoPkf2iUpDxyehdFBDahS08eSYMuXoWbjnWRO+zwXsc9XkUC0aG9P2uJqq rwFA== X-Gm-Message-State: AOJu0YzAmuGzXHj+/ZuK3cLGz1pyWGWIpD6EkhyPeUhoULackFow22sj yWFzb87qCv1UOjxBP/ZcFRZl3FHyFINTMhXyAyXJPjEF1OS1iDiqPPao+HQFWCw= X-Google-Smtp-Source: AGHT+IF3O82dyPropNxIrPw7AT0nWsogrDtS7L+OD3mfTQAdEKRPQjfJsOJCozaG5fx7YcGj0eMOzw== X-Received: by 2002:a17:90b:785:b0:2c2:daf4:5e5d with SMTP id 98e67ed59e1d1-2c4db44aa13mr9229429a91.24.1718660415580; Mon, 17 Jun 2024 14:40:15 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c4a76aa24asm11667143a91.54.2024.06.17.14.40.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 14:40:15 -0700 (PDT) Date: Mon, 17 Jun 2024 14:40:13 -0700 From: Stephen Hemminger To: Isaac Boukris Cc: users@dpdk.org, Konstantin Ananyev Subject: Re: dumpcap: weird failure with six IPv6 hosts in the filter Message-ID: <20240617144013.0bbcece1@hermes.local> In-Reply-To: References: <20240617083049.412242fb@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Mon, 17 Jun 2024 23:43:19 +0300 Isaac Boukris wrote: > On Mon, Jun 17, 2024 at 10:37=E2=80=AFPM Isaac Boukris wrote: > > =20 > > > Just a quick update that I still see the issue in my env with the > > > master branch (24.07.0-rc0), I'm now testing by adding the filter to > > > 'sample_filters' in test_bpf.c and running: > > > time sudo build/app/dpdk-test bpf_convert_autotest > > > > > > With 5 hosts it takes less than 2 secs, with 6 it takes about 25 secs, > > > i'll try to strace it maybe. =20 > > > > strace was useless, no syscalls for ~18 secs, not sure how to debug it > > further, valgrind / callgrind don't work on dpdk.. > > > > It doesn't seem to be about the size though, I was able to produce > > larger bpf code with ipv4 addresses and it worked fine too. =20 >=20 > Debugged a bit further with gdb, it looks like it is stuck in a while > loop in lib/bpf/bpf_validate.c:evaluate(), there is a comment saying > "make sure we evaluate each node only once" but it seem to go back and > forth on the same idx's afaict. No idea, only original author understands the verifier. Having our own unique verifier may not be a good idea. There some other userspace BPF projects, seems like a good place for convergence. https://lpc.events/event/17/contributions/1639/attachments/1280/2585/usersp= ace-ebpf-bpftime-lpc.pdf