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 5CED245F6A for ; Tue, 28 Jan 2025 19:46:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F7E840151; Tue, 28 Jan 2025 19:46:22 +0100 (CET) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mails.dpdk.org (Postfix) with ESMTP id 8C13940144 for ; Tue, 28 Jan 2025 19:46:20 +0100 (CET) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-53e384e3481so5720615e87.2 for ; Tue, 28 Jan 2025 10:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738089980; x=1738694780; 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=zfluqS8y/xsBOlyOOzgyiOVu6Sz5iHeQ1ZM4HprfaeA=; b=bhpCGXd/2zy89SEXTI69iJc/ZiClw8C/G0zC+tMGBpgvEKyvamtH6mxy46Xo2TkkjW ENQF7z4O1jbXo1uYVuCaXlU8IhAGwixpoJdwJygryJRDU9uZDwc+0MxrditNEW6Pjt1/ s+0QZ4TCmX0cvxSvM+zfOlXHXHhGFLBx9c0Pf7x/RVJuLuuywfOi41fEZutwrmPsnLfa s/azkMR+vrx5vi2XxKUALN0Ca8yuGFEbUcwLuPbQca1l+xY2rISzVd4drwAesViOWlnp YbGoi3LEhtWwY1xsc7UL7OEtXIwh0aLM3nkDgcyfThwlgxceDRRSAk2VPWJqM8vN/jxe SNjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738089980; x=1738694780; 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=zfluqS8y/xsBOlyOOzgyiOVu6Sz5iHeQ1ZM4HprfaeA=; b=jA3/gc86z1vVOkyXoVYGRq+QIo3mTijemKna6q01DdvizGV1pNkQ8xNUFduvs687u2 MTZMYI3e98NqsoLGi4nUmIX/liCakIGEurMOkNDHIqmOfbXUtJaz4Q0d3zXeVZXQt9tM 6t0lb6uqwkeJbFTuIFZbugzqStfUn9sMDg0CgzPyYjnPf9Lpw75lefDX1JKMFPImEmcl j7TbKWYZOFm3r3HzdZdrEiK0TJh/WL5EFZtB04ru8STcWmtnDj3yP/z9J8fwi7ImmAF+ 5CRYn7nE9Se+rRsaqHDWEOKy+JsfBoViJNGgv/P5kP/iXNFWGvk1VymAWauvThP9MVBK Ye3Q== X-Gm-Message-State: AOJu0YzQjjcCvY/5DKNxkv656c/CxFtyWtlJReVEqsl28JaW4F1q04g/ Sn1tgF5UwlQb9Z16RThAr2SRxPRc1cJrxoqZ8sObTX0/aeEQrl5/ X-Gm-Gg: ASbGncvGvEM49n/5Z070pgatdG4qPyoLjyFCQpqSSKgExAfMM7YM1rzZL076KDCzRQS Z9OfnDmzsY6d2/JPYuH+hf/Wb+4yJZFTzJhaIvHNOEj4PCI1Oghn4U8L6dUceuUp9x4fY6aEPeI 3TzfPhgXtIPQNvX0xMdybDKGn4fLaTYz6Vi6sy8x0aiuE8GhDpFVXcX75dA+DnA7eVrVUnzjM0+ QZIJQppshIKUSiFobp12si6rFJbZMjOXqHEVxH5XJpdkBYEmqpUzmJyLh1O33FtEF1gexzVdOpu iJylrqQCbjezHjaS7jIYr7qRvsJDYBlknJbB9V3XuDXhCAUe/kb8PdpKO0nr7Qs= X-Google-Smtp-Source: AGHT+IElaO+lorSy5LSrw2VXdB245Z2eQbTf0OLXbXm2aTohLC6zSIL55uuymSbiI4djisMPhWp7aQ== X-Received: by 2002:a05:6512:2244:b0:540:1d6c:f1bf with SMTP id 2adb3069b0e04-543e4bdeee4mr63220e87.11.1738089979533; Tue, 28 Jan 2025 10:46:19 -0800 (PST) Received: from sovereign (broadband-109-173-43-194.ip.moscow.rt.ru. [109.173.43.194]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-543c837e21dsm1739616e87.215.2025.01.28.10.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jan 2025 10:46:18 -0800 (PST) Date: Tue, 28 Jan 2025 21:46:16 +0300 From: Dmitry Kozlyuk To: Sid ali cherrati Cc: users@dpdk.org Subject: Re: DPDK Flow Filtering Not Working as Expected Message-ID: <20250128214616.3f9324de@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Hi Ali, 2025-01-28 17:54 (UTC+0100), Sid ali cherrati: > I am attempting to use DPDK's rte_flow API to filter incoming packets at > the hardware level. My goal is to drop all packets except those with a > specific IP address and UDP port. > > I have implemented the following flow filtering rule in my code: > [...] > However, despite this configuration, I continue to receive packets with > other IP addresses and ports that do not match the specified filter. Packets that do not match the rule pattern are processed as usual. If without the rule queue RX_ID could receive any packet, it will also receive them after the rule is created. You need another rule with lower priority (BTW, 0 is the highest one) that matches all packets and drops them or steers to other queues. If you want your DPDK app to only process packets matching the rule and to leave all other traffic for the OS to process, flow isolated mode may be what you're looking for: https://doc.dpdk.org/guides/prog_guide/ethdev/flow_offload.html#flow-isolated-mode > Could you provide any insights into why the filtering isn't working as > expected? Any advice on ensuring the rule is properly applied at the > hardware level would be greatly appreciated. The usual way to check that the rule is matched is to all a counter to the rule and check if it increases. I suggest using testpmd for playing with flow rules: https://doc.dpdk.org/guides/testpmd_app_ug/testpmd_funcs.html#flow-rules-management There was also a useful talk abound HW rules debugging on DPDK Summit: https://dpdksummit2024.sched.com/event/1iAtU/debug-functional-and-performance-issues-in-rteflow-dariusz-sosnowski-nvidia-corp