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 ACF4443270; Thu, 2 Nov 2023 17:58:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9865141101; Thu, 2 Nov 2023 17:58:10 +0100 (CET) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mails.dpdk.org (Postfix) with ESMTP id 080AE40144 for ; Thu, 2 Nov 2023 17:58:09 +0100 (CET) Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-6be0277c05bso1183189b3a.0 for ; Thu, 02 Nov 2023 09:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698944288; x=1699549088; 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=DSpVhuREH71V1O00qgT+o61MfLMlaDtmym7HFsdI5a0g6NBwCpzKx+j+rdKihF+sUI hKzFonj+NgI17G+qsZsIjYJo5B7tT/7F2xUiSIqMngN/pWhSvzCle213ozZ8GhMV7SNo uITfUP59vQ0XkzFe+coGPA1W3kKwh5fFFiIB6YZSDpI2SOWVdQYEm8YueCJ/W3yn+65M 24oIgThw7m+05VOkBitl/SFJxUkih51VzwEAW6PeD7RAd71+tUvixkiG/p1HSK6vggMN lZR6daRKWNupTVSXG5qkZUIGhhRYZGVetmCiOvp/LTpdC/HUcC+21KYNjqRcctNTKguk SdIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698944288; x=1699549088; 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=VAfP1q111KF8f8inIxYPkJ11RlarQ1BNhKduA1rW/icHc/TX5vd9swXdju6ZZhBD5x P7/XIF/i7+LlKAuVtdIq97p57DeMuCldvEMyf1ByRoOxWBSyvKAZ9LjmvXQUeojeTbXF AXoCfj3+lAKMlQsjM/3PBYv5RCfQ0Wb6OB+BlVeNl+sIPiMmcDUdy87a/ePnumTDEaik vEOmTmOs6a8Z2jaVe0NfpTJizqcLPFcByGQG54IZolxIRpaZNtdpNFQRSpklxrYUvmhb RvLHthp3oYffoVbojpoUUgEdzmsaaI6QHcPy7GNoLoGsh7/wX3NrwidJX8kmowAmdk0d EY8g== X-Gm-Message-State: AOJu0YzrkbPpJ4yBhYOXg6fmW4gn6rSgKf3vxg5IDnw/4alyadKUb6lZ Y1QK2UEBnQhwmPN3Lw+QH6Bd9g== X-Google-Smtp-Source: AGHT+IE2Bsn1c5YhN+LKcbAEG1ojLXS/brDlZPrwZQRPATFCvWfDp07spYYF1s9tk4XNYAnz//jEYg== X-Received: by 2002:a05:6a20:3d8f:b0:172:913c:ba36 with SMTP id s15-20020a056a203d8f00b00172913cba36mr18198164pzi.24.1698944272073; Thu, 02 Nov 2023 09:57:52 -0700 (PDT) Received: from fedora ([38.142.2.14]) by smtp.gmail.com with ESMTPSA id s8-20020a056a00178800b006c2fd6a7fe3sm3069pfg.22.2023.11.02.09.56.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 09:57:20 -0700 (PDT) Date: Thu, 2 Nov 2023 09:52:34 -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 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. 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.