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 E505E4550C; Thu, 27 Jun 2024 17:36:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 78004427A7; Thu, 27 Jun 2024 17:36:47 +0200 (CEST) Received: from fhigh5-smtp.messagingengine.com (fhigh5-smtp.messagingengine.com [103.168.172.156]) by mails.dpdk.org (Postfix) with ESMTP id 31CA140BA3 for ; Thu, 27 Jun 2024 17:36:46 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id A5314114010C; Thu, 27 Jun 2024 11:36:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 27 Jun 2024 11:36:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1719502605; x=1719589005; bh=v4aFcHDcrN8opCECxMZ/av+nyDxNnqAT7sWnrHDdoDk=; b= YYmwbtccFSZKuDEBxA4bq9RvF5UYD6dzclW0OhISBGtzlZsQ5Z+kgWNv4+Y+AuSh vR2MMJ8NPd6zSWkM1N0eRqirNXgoukoVgvTq3RgAnWVnae20PlA6zKZzfta1L3aS CqMVDHu4kiqHDH8d77obmOQoJoeoS3wI3PndoxPKM0DXU8vWEOovWPy9rZFthPnw BvwzK3VAp0TUrhpAkEf8iYcrHiuRS2j7/EY3brIpjCs0zf5W2OLIuY81lT1IW1yJ agEXpZJEXeyb+eLC4cFEF0sS14tGEh6BmNCZW0qbru+zrclrL6bnROxvW23hM++/ lBOYI0UORTqXxdruQrxK6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719502605; x= 1719589005; bh=v4aFcHDcrN8opCECxMZ/av+nyDxNnqAT7sWnrHDdoDk=; b=b A1ovmlNwG+oakS8isTMdDz/kg/LOPM+uDI6MSxdJjK1hNS3LLr9LgA/LBrgSPZSK WlOlItf+W94A+gKGD39DUAV/dAYGSzcItoUzQImEPiqoJ0/kk1G0nZPizj5WO+Qq Ftl5lnmOtw0alnAYVB8DTFj97nfZRYMRM6HJN8yRQIL5L2JXojfjWRez74b6YvzQ NjG6Y7nq8eAgme32zCeZb4E1mdBSZM413nBeJoBgGOusekrAVKSdv5FUBXyWvzY3 UpDxMJ4dHqvKGOcd1mgwvaBiyoh6lf/WB31y7sieuoZzpmXxUEKmdIbqUgTBY1NB 3dbWqcql7bgkjVELkleKQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdeggdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeduveehieevuddutdevfffgtdegkeeuveejffejgedtgeegkefg vdeugfefkeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jun 2024 11:36:44 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Yoav Winstein , Konstantin Ananyev Cc: dev@dpdk.org Subject: Re: [PATCH] bpf: don't verify classic bpfs Date: Thu, 27 Jun 2024 17:36:43 +0200 Message-ID: <4846180.STdkYbjpsp@thomas> In-Reply-To: <2eaeaf90d9a94c8ca199f5bb51e0ba38@huawei.com> References: <20240512055545.98297-1-yoav.w@claroty.com> <20240512090325.7c085db5@hermes.local> <2eaeaf90d9a94c8ca199f5bb51e0ba38@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 16/05/2024 11:36, Konstantin Ananyev: > > > On Sun, 12 May 2024 08:55:45 +0300 > > Yoav Winstein wrote: > > > > > When classic BPFs with lots of branching instructions are compiled, > > > __rte_bpf_bpf_validate runs way too slow. A simple bpf such as: > > > 'ether host a0:38:6d:af:17:eb or b3:a3:ff:b6:c1:ef or ...' 12 times > > > > > > results in ~1 minute of bpf validation. > > > This patch makes __rte_bpf_bpf_validate be aware of bpf_prm originating > > > from classic BPF, allowing to safely skip over the validation. > > > > > > Signed-off-by: Yoav Winstein > > > --- > > > > No. > > Wallpapering over a performance bug in the BPF library is not > > the best way to handle this. Please analyze the problem in the BPF > > library; it should be fixed there. > > +1 > Blindly disabling verification for all cBPFs is the worst possible option here. > We need at least try to understand what exactly causing such slowdown. +1 You didn't mention it is also breaking ABI compatibility.