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 C252543270; Thu, 2 Nov 2023 17:58:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B21B1427DA; Thu, 2 Nov 2023 17:58:16 +0100 (CET) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by mails.dpdk.org (Postfix) with ESMTP id 64F9240ED8 for ; Thu, 2 Nov 2023 17:58:15 +0100 (CET) Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-5a9d8f4388bso822314a12.3 for ; Thu, 02 Nov 2023 09:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698944294; x=1699549094; 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=3l2ozcnPtnX+U/Ia6Z455t5hHcoOdaWxMvtgwVc7aW4=; b=hAefDlGWH2vbnZ5GEI/vKcrgSszjSQxcdv89CTFeh9XrsQqGIomUkQSlSCGz+24t+r tDwOd1220K92tRX45Aaod9HJ39rs/6DNUChRfVJUubYuEUinPsoPcgjS/4Gk+r034t6o rAnfy96ICef9lhjiNzvY8Zsz910sUGEORK4VcEQJEAXljeN5nzPpLiBiP+LrKtkgreK+ wrWrI6OtnEg6FtVSTKl8yDPAM94v4MOdGpFJ17eSXCxYyfZcWNnRPjioUEhn4C6afcj1 /+fPXW4gqQyCLFWrelmMrfpZdS3+0vL+Uza7wlqKbYs0T8pMQVnqs70faOJih6as4pqi zyMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698944294; x=1699549094; 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=3l2ozcnPtnX+U/Ia6Z455t5hHcoOdaWxMvtgwVc7aW4=; b=jb0b3D1RnFXisF7xChBt7ueI+1Ufyj9/XPrnQccjHi+zi8R33wHEJnuG1op8qZ+5OK tc5KD3mk5sm3RCEOASflcyCROF6TcheP/D4voVBknGfkVwTshmu0bsrH4USRW77Stjsi IwTbJlpEsVtFEHeNd8o/BLnRguvixnYiDKFvws2QDxbFMyIplkUJyE39TAyPzJWT0LxS iCWspP27fKygkdI65tI2e/9IYDk1OGt5Oo9HzTaVmHbflhRm2r+ZLYgDmWep3QWqlozC AcgidfxZ12II4vsRSjb2QNAgQyQe1gbriXsW8I98x00xoemirJhz1pMQCr1qz+DXNLyJ Yncw== X-Gm-Message-State: AOJu0YyuHNBohSLEuiGRHF93xZbgCwOEeF7PazAHjKjucRC4sKqNoRuz m1wM8fmoWjBe2USiUt260eoTI+jsMuzxmoc25pFn7070 X-Google-Smtp-Source: AGHT+IHIpgflQ3021Q9Tl27RZQQ+hV+wEeFK+i+VwCbenLy6tlz5lEgT2GW4mWaJ9rkRN/95QLrPRA== X-Received: by 2002:a05:6a20:12c2:b0:16b:c62d:876 with SMTP id v2-20020a056a2012c200b0016bc62d0876mr19252624pzg.23.1698944294591; Thu, 02 Nov 2023 09:58:14 -0700 (PDT) Received: from fedora ([38.142.2.14]) by smtp.gmail.com with ESMTPSA id s8-20020a056a00178800b006c2fd6a7fe3sm3069pfg.22.2023.11.02.09.57.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 09:58:02 -0700 (PDT) Date: Thu, 2 Nov 2023 09:52:42 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: dev@dpdk.org, "techboard@dpdk.org" Subject: Re: [PATCH v6 0/3] net/tap: build and fix for BPF program Message-ID: <20231102095234.0e351fff@fedora> In-Reply-To: <62d85cfd-596e-4efc-a084-e14fab932956@amd.com> References: <20230716212544.5625-1-stephen@networkplumber.org> <20231101180526.214773-1-stephen@networkplumber.org> <62d85cfd-596e-4efc-a084-e14fab932956@amd.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Message-ID: <20231102165242.N-OXwso9K_R0ZnMNu8SYqjMVCHDNUIaqw4SJSH-2PG8@z> On Thu, 2 Nov 2023 15:11:10 +0000 Ferruh Yigit wrote: > > Stephen Hemminger (2): > > net/tap: support infrastructure to build the BPF filter > > net/tap; rebuild and update the BPF flow program > > > > Thanks Stephen for fixing this. > > > But considering it was broken for a while and nobody complained, and > initial developers seems lost interest and it is relatively hard code to > maintain, do we still want to keep this support. > > Can we probe again motivation and benefit of eBPF support in tap PMD, > and if it is still relevant? The use case was allowing an rte_flow match to a set of queues and have the BPF program do RSS across set of rte_flow queues. Simple non-rte_flow usage of TAP doesn't need this in most cases. The kernel will do RSS already to multi-queue tap. The motivation was to allow use of rte_flow in the failsafe/tap/mlx model. This is the legacy model for use in Hyper-V/Azure. Not aware of any application using this. The bug fix came from Oracle, perhaps they have more context. This fix set came from looking at old unmerged but ok patches in patchwork.