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 17C2546190 for ; Tue, 4 Feb 2025 18:41:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D24144025D; Tue, 4 Feb 2025 18:41:27 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by mails.dpdk.org (Postfix) with ESMTP id 94448400EF for ; Tue, 4 Feb 2025 18:41:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738690886; x=1770226886; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=gdW5KKWw30Ux2OCR2fnDG2wld/pu42X9Qi9J93XVazo=; b=L4yK7y41mSehIk6szbJ9zcpQgp9fJpltNHGL8OptLwIoJbXwk4e5kYow PGpm6i2dXtvqby4vaqlNC3tadnc9qHGib4lCecQCvLMlwAmbk/guzmqDa RrsVxYP/DzAvFYHJLaW9Ey2Ap9sBn6fTIp11LcnRLFhrHzxJfdBMKfder +upukivhEmURm92xo4WzxbIynMXzWNKa/tGgRvAj69c5OaLnVOZgHx+Cq GEWcf+lcRKCZapmr7rGOfksib/xAbot+xNHaArAoc95oEJAiSeViKjTPz l7s5jUZUmbT+UqOq9pq2fZ1e0ynYa5vD8Qu/FklJ2PanbCbJYB1JAA9t3 w==; X-CSE-ConnectionGUID: ZtGOvI6GTZGYs4wZA+96cw== X-CSE-MsgGUID: oux5Y178Ti+/oZ87hlmdow== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="64584857" X-IronPort-AV: E=Sophos;i="6.13,259,1732608000"; d="scan'208,217";a="64584857" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2025 09:41:24 -0800 X-CSE-ConnectionGUID: OWRynyaNTjOx+zL0sVG37w== X-CSE-MsgGUID: MHvinhHhT2qH0TKpZPyz/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,259,1732608000"; d="scan'208,217";a="110496288" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmviesa006.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 04 Feb 2025 09:41:24 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Tue, 4 Feb 2025 09:41:23 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Tue, 4 Feb 2025 09:41:23 -0800 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.47) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Tue, 4 Feb 2025 09:41:20 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J37iAqUlqUCH5hsvQ0Fa6cT6skXMfLMhQeL0S3pxvzeqG44tZ6/k6zwl1kS93gnm6YfdPYcMNAA5FBixTLaoDUGGW97bx4SqqGYtpHzEUMhnom2FXO4UxjC2nlqKJLyAzI0p3cPyC1upFaPswr6DEpCjC5+tZxsrWZKLtHB9sZPhtZ/mZYB5A87k5xIDzzRH4sOH9mk2GdLe1Wnk7RVIQm38jdyufIRRLxTq6UEwxLO5G8H3kB0eL9NXbSVfmSRG/r41rnBn34ZI3rNW8KtgjzOLHJ+sh+Ge7huzxiT3W92AIYLVXIMv5hX6pbx6NJrBbwYxYJi7kXw9ZUZalrdssA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FPUpVg0npcwSmF8yoRYFbHLI+ZEJn2Qhx+j81DscHw8=; b=PPfrL5IgL2UXEo8brXc1NSvZUBTxTQt/cx4w7D4nUcsivcfcA+Kkt1zD7sgKnsjjeDQChSm8as9fiI6++WoSnr0JURsLb50kW5hcsJji7hyH5bdWNYeJx51ShyIImDEzi5Y1OS5fujc/fj+H1UxR3GSJSaMB3hqR8FJrN/BAH6HFnowFeCIr7qshKUcBbJLZyG1O531W93QQPKpoHV2XLuTYiDOkB35/ay3FxsqZ1eyyIrb7itok1/ZBHhoaViathzk9n1yzH3Y5/ZetwvAjBVsQIMxrIBKpuRILa1aOcpEfWfzSSZEqm17sCkqBRmgIEXgb1X0EWjdw/wCAgY+UXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ0PR11MB5772.namprd11.prod.outlook.com (2603:10b6:a03:422::8) by PH0PR11MB5048.namprd11.prod.outlook.com (2603:10b6:510:3d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.24; Tue, 4 Feb 2025 17:41:19 +0000 Received: from SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b]) by SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b%5]) with mapi id 15.20.8398.021; Tue, 4 Feb 2025 17:41:18 +0000 Content-Type: multipart/alternative; boundary="------------Mo21uRIqPVND16llvnyKk8Eb" Message-ID: Date: Tue, 4 Feb 2025 17:41:15 +0000 User-Agent: Mozilla Thunderbird Subject: Re: DPDK Flow Filtering Not Working as Expected To: Sid ali cherrati CC: Dariusz Sosnowski , Dmitry Kozlyuk , Anatoly Burakov , "users@dpdk.org" References: <20250128214616.3f9324de@sovereign> <20250203180007.2c5e0607@sovereign> <2a89c290-48c8-497a-82d8-6a9a8bc5887b@intel.com> Content-Language: en-US From: "Medvedkin, Vladimir" In-Reply-To: X-ClientProxiedBy: DUZPR01CA0022.eurprd01.prod.exchangelabs.com (2603:10a6:10:46b::12) To SJ0PR11MB5772.namprd11.prod.outlook.com (2603:10b6:a03:422::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR11MB5772:EE_|PH0PR11MB5048:EE_ X-MS-Office365-Filtering-Correlation-Id: 29659068-da7f-472f-39ed-08dd454321a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|376014|1800799024|7053199007|8096899003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VzVrUm5odzJ1bDd3T1RDNG9rSVFYY25MblRWbEtidEVsNFRhNW9ZU0Mwd1Fn?= =?utf-8?B?d3U3TUNRdUxwcitlWVhHTUJrWUN0U0VHR0c2Y3NNcHMyenlxU0JuUjgzaXY4?= =?utf-8?B?WnJmRUE4SUUxZS9ONjlqRk15TlQ2MXljcjRwZHhKL092S1VyMnFZRll4dW1w?= =?utf-8?B?VTBWMEN6QWhnSE9JKzAwaFg3NmlMN0wrTEowQXBmSm5ORzA4cGxPcS8vNU5O?= =?utf-8?B?QU1QTVRUcEpmamNMbkNxb3l2QTJPUkhReW1OZlBjSXgxaCs3ZVMvTkloa28x?= =?utf-8?B?UkttZ3ZxMmlDYUEzaEZwNjhEbnEvWnFnTWEvK2tLL0phU3NydkpZbnJDcTBo?= =?utf-8?B?dmo3MTZIUERmdHBicUZzelFNazdBdkM3eVg0OThseS9kYkc0dUxtRnE1V0dr?= =?utf-8?B?eVhqeTRHdkZFZFZESWhIODh3ZWZpN3RUYzBQY2lHWTdSbDN4MytYM3hSbDBt?= =?utf-8?B?NG1mWmF0NXhZcHM4NWRWVkVXMXp3L2xQQkF0MGxuMWtSYitOcHptSnZNaWdJ?= =?utf-8?B?bjJxTlJ1dUhQUXQyZUprYzdjc0hEVXBUTnZVbkVISDBUR2NuV0o4YU9TRVlP?= =?utf-8?B?OTNuc2taYVFnUDg1Ynl0K1VRckk1Y2dqNUw5cDlTRzBEZnh0VG1PSWgwZlJJ?= =?utf-8?B?Y3grbkRIb1Uxb2ZCcjBDQ0NqcERHLzBMNmQxQjBsWWliTEVTMU81OXBTNlZV?= =?utf-8?B?UmErRVVUdjdjaDNYbk41NGJoMEdOdVBCVzBkTFpYbk1RbE5zNEsrZXBYVWN6?= =?utf-8?B?TWoyUlNGaVZlYXFOLzlJTFgvZGdwb3hZZlZHczhvdU1kZlk4dFhsQkp3TDJS?= =?utf-8?B?SFRXLzR1ajViWWRIeENyYnVTYWt2S0FLSll4SlhnbVJtazBoU3hmWWtXN1JD?= =?utf-8?B?VUhzcnNrN1V0dDR0V2V5RDhqZmh3NDZrQmg3V0owYnRRWjNTRDZrTGNYSGxT?= =?utf-8?B?MHNZOGwyekdPdzEyQjZTTWNsV1BSMmh6N1hUNExkN1B3UytQZjMwMXI3b2sz?= =?utf-8?B?V2loYktRTlFpNUtHbEg3OTIzWjdJbGV0UU9JQk9GdCt0RE9UTlhlaUJ2TlI4?= =?utf-8?B?L1dpVGd0MnJvV3I1SERyaWdjcFhrcS8vRDVmUE4vaGovZllsRWZ0WmdMeWgr?= =?utf-8?B?TzJjanNrV0lnYXBLR3pubnEwbFlwY1JVaWhYbEFvWnZDcjlra28vY3Q3UXVv?= =?utf-8?B?THdzZHBJTU5CSnpBRnlzTEZCNEl0STE4N3dtbTFtd3FJSVZTK1lveTBMd1gy?= =?utf-8?B?OTFscVMzelVrNENoUjIwWDltZ3FTdE41UDBzN3NDM2JaSHplLzVMUDBjWlBs?= =?utf-8?B?THBxbjFaQXRrQU81elFnZFBkS2FtUTVEelRpUkF1cExhZmp6MjVOQWNVNDNN?= =?utf-8?B?UnBVWXlIY1I3SFJkWkVyS2VlVkIvb2NoSnNQU2hlY2ZLa3B2UnFqV3lhZEFL?= =?utf-8?B?aWtiTVRHY0krUEVITjFsdkU3SmI2SGd3cmwrYTFYQkZwSmdoNGZ4dXJpZHZZ?= =?utf-8?B?d2p3akNic1NYc1kyZWNRZzVGQUkwQTRqMVRwbm4rN3MybTZRZkw4R0Y2bHJ1?= =?utf-8?B?L1RHZ2xkbWxRTGNEYnQwSlVnYjJIeS9OT0FsNjJSNUdIL3BnM0VZbE8xbk41?= =?utf-8?B?Zk5WK1pEN1ZYSG8reGxhVGgyM1dGS1VKbktQc0gzbElQMHJPa1d0d2x5dVlq?= =?utf-8?B?Y2tVYzFLdmdoeURWdTFxQUJNY1dIQUVDTVhJdGo1ZzNrbGRSeDFtajd1VHlz?= =?utf-8?B?SUFTS2Z3cVF6YkZFNTlmbEJDY2NoSUsrVzMrMUorOE0rR2JrRGxJTk1icnUv?= =?utf-8?B?dUpwdXkxeVY1ZEMzVmtOeXZtWUpBWnhlZ3E4TENVTEgwOG9nVmRtMG4wQ0tl?= =?utf-8?Q?DKKbLx62q6S9g?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5772.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(376014)(1800799024)(7053199007)(8096899003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YS9mZUIyeUgvWlNISm5tajc4T011R0l6MWl4bUlDUytsbFF6TzdVL0hrYk9y?= =?utf-8?B?K1Z1djJKWGpaUWNFNzNJMXp2R3FnRG52S2JBM054R1hLRXVFVjVFREY1MkRO?= =?utf-8?B?eS9VelZhdkxvaUVCeVFDdUloeFNjdVRyMHNtWnNSSkZHZFNDUnhZUXNCcS9o?= =?utf-8?B?dUFzeUkwNnVFUEM5ODljOUlPRHU3VnhsbzVhMDRkT21HcnhiTlg5NjB0N1dr?= =?utf-8?B?dHZQK1BxcTlSTko1dlF2bVN6aU1kZHhoWmJCOGZYWHJ6M01CbHU0VDlHbmhm?= =?utf-8?B?SThOYS9CR2J5VXFIelI4MlovSW1FZlBwZFdWaHIvUWVMZ2ZQcFdnTmdBR2Jo?= =?utf-8?B?MC82TnVuSWt5REFwUkNCWWZBREJPaERaenA1YjNycUsxUnQrM200WjZpc2hJ?= =?utf-8?B?elpsci9TMDN1R242WTU5dUR4b1ZmVmRBazg3UGVkVkVPbGkza2JkVmFCbU5i?= =?utf-8?B?Slo4V2FNbml1Wm0zTThFU3B0Zk50OEM3eGdIMEs0R08yanV4Zzd5bWZjT2tV?= =?utf-8?B?KzhoV2d3SUkrNiszSm1XbjErbVVDOVA1NEJxY0dCQytIVDFYYUYyKzVQQkV6?= =?utf-8?B?cTQ3S0V3YTZTYW5KMzg5L2NCRVhOeWQvNXFmQnA1WEJVT1lhOW9obkxSYnZx?= =?utf-8?B?TnB6RjN2cG1TcGxLNmlET0hQblQyQWpMeGM5d3pyemdDZElLa3VuSDJGU2w4?= =?utf-8?B?V20wMkJhTWRxT0tqcXVMRWxncktGMFM0QWg4aXB4bkJhKzM1OURiSHJOb0wx?= =?utf-8?B?ZTluNXpoTmJuVlp3dllNYlN3UVd2WmVZeEEwS1NTb1FvczBybmQ5U1ZIOWFn?= =?utf-8?B?VmFPWXVwcG9KUURaMUtFV2NDWXJNNVZ5a3FOV2JVbDJVZW9oSUtGdUkvN3lw?= =?utf-8?B?NHZnU2hCNmQzem1nUlhwdXJXQUdzTTlVb2pMSXAyMFZQKzlHVUpldkdiR1Az?= =?utf-8?B?MDJabCtRRTZUK1dFYnpCOWRucmJOdVR0Y01zQzVuUXlQaFRTdzk3R2JiWi9u?= =?utf-8?B?RFJQTURsWS9neEZXaXVrcS8rZndwSFh2SCtYcG40L1p4blpTMlhERlhqcWlm?= =?utf-8?B?L2ozR0dDVjFna2FrNFlqd3dsWS9qV1lydXBZWGNWNWJrclFOMU0wZHNsN2xP?= =?utf-8?B?Y0ozTnJ0eW91cXViUC85ZVhkQkxSRTNXdGF6eGpuY2pJRUtOWkRWMUsvQlZp?= =?utf-8?B?K3IybWVNTkRCQVpGMlBvUWZrZlNpbnJoYVpNbUZpcXV6TDllOFp3elRvZ0tl?= =?utf-8?B?bmtBTlVTMDZiY3BtVEJnTXNOUnpiMkIzMEUwRVYxeEpkOUZmVjhKaEZIM3VQ?= =?utf-8?B?ZThqbWg5ZE9Jank1OVFnVmJhdEJqb2lROGhFQU1JM0RDbU94cXY0R254ejk5?= =?utf-8?B?L3M0U215WERqU09ZcHhieEVmYWl1cUxLZVJLSXVhV0hZNkVmT2YxMkw0VjFD?= =?utf-8?B?OHJWMHVDVVY2OG5zdE0xZ0dkekpocDZCQmpVS2ozRzhCRkNEZG5rS2xMQjBZ?= =?utf-8?B?Z0l2THdVU05uLzh5ZWQvV1ZSQ1o5M2lsU1Y2S2d2ZThlVVdwOUs5dXAzYzAr?= =?utf-8?B?RWg2b2M5TW1HNmJzTmw1R3Nhc2d1TGQ3bVdaUmNSRXE2QXEwMG1ibXNucWR0?= =?utf-8?B?WmMwcHRpWW1TbzUrVVBJZzNER3VQbTlWWWNnUFJRTjduVVJGQUpkUXA1b0pt?= =?utf-8?B?RHVIZURtRU1wc2NNNGdBOVR3MjdzZ0xXYWZES1NXOEVjUU1qZjFDL2gyUitI?= =?utf-8?B?eGN5a0VteTFJUndESzJWektWRkdlZC84MnRMUlhLYVM1bkdkMEFPaFRBb3RN?= =?utf-8?B?T0d6dHo0b25jcVBCYTZSRkorT0dsRHl5LzdpODIwZzJwbldneUE5L09wcmov?= =?utf-8?B?N01JSkU4YUJGTFBUaHRDSkV1bXYxdk1FNnl3eEtTSFMzOEtNOFE5ZFJORHhQ?= =?utf-8?B?dGpFVC9HZm5OY3Z1cWViN3FNa094NStURXlNZm5tSkVWSmtFOEYraFpBcnB4?= =?utf-8?B?dTlSZVdkbVlkQnJxLzRIVFdsRmN5dWdpSS9QNHcyTlhUUWIwc2lCNCs0N1Qw?= =?utf-8?B?SHBXSlFlRVcxYkRwZ0pqbGtvT1cxR2J5UVZPTGc2R0VqMFlodzRHV0drb015?= =?utf-8?B?d3UzbXVyeFpGTkVvbUZBTnlMS3ZrbHNreE13aGtTbEQ4azN5RnVFRnkwWmM1?= =?utf-8?B?dHc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 29659068-da7f-472f-39ed-08dd454321a3 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5772.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2025 17:41:18.8869 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: lGEDceDf7ZTrEbZfJknuviRAjGQFO16T2RRPcEE2+y1kJsy326Z2eVD6PmAZ8OjGFlwrWOtpzkZ3MLzzq4VIILOqk1oA51z/pNzRiVeMfyE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5048 X-OriginatorOrg: intel.com 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 --------------Mo21uRIqPVND16llvnyKk8Eb Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit You can also try with the existing X540-AT2 NIC the following : - Init NIC with 2 queues - set the FDIR flow for your particular ip/port to route your packet to a queue number, say 1 - Instead of using rte_flow to drop all other packets, use RSS. Rewrite the RSS ReTa (see rte_eth_dev_rss_reta_update) with queue id you are not going to poll, so in this case with queue id = 0. All ReTa entries will be 0, so packets not matched with the FDIR will be assigned to this queue. - ignore rx on the queue 0 I believe this approach would be better for your particular use case, than relying on rte_flow to drop all the traffic, which, as we could see, depends on the internal HW implementation. On 04/02/2025 15:50, Sid ali cherrati wrote: > > Hello Vladimir, > > Thank you for the clarification. > > I'll try using the E810 and provide an update on the issue. > > Best regards, > Ali > > > Le mar. 4 févr. 2025 à 16:41, Medvedkin, Vladimir > a écrit : > > Hi all, > > The goal that Ali is trying to achieve is not possible with the > X540-AT2 > NIC (as with any other ixgbe NIC). The problem is related to: > > 1. The first rule is processed by the FDIR engine > > 2. FDIR engine is executed in the HW pipeline almost in the end (just > before RSS), i.e. after other filters that we could use to match all > other packets (5tuple filter engine in this particular case). > > Therefore my recommendations here would be to use a modern NIC > such as > E810 to implement the required filtering logic. > > On 04/02/2025 09:28, Dariusz Sosnowski wrote: > > Hi, > > > > Anatoly, Vladimir - Would you be able to help with the issue > regarding DROP action not being supported on X540-AT2? > > > > Best regards, > > Dariusz Sosnowski > > > >> From: Sid ali cherrati > >> Sent: Monday, February 3, 2025 18:12 > >> To: Dmitry Kozlyuk > >> Cc: users@dpdk.org > >> Subject: Re: DPDK Flow Filtering Not Working as Expected > >> > >> External email: Use caution opening links or attachments > >> > >> Here is a better version of the code : > >> > > >> > >> Le lun. 3 févr. 2025 à 16:00, Dmitry Kozlyuk > a écrit : > >> 2025-02-03 14:51 (UTC+0100), Sid ali cherrati: > >>> [...] > >>> if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)){ > >>> flow = rte_flow_create(port_id, &attr, pattern, actions, &error); > >>> } > >>> > >>> if(flow != 0){ > >>> printf("Filed to create drop flow filter \n"); > >>> return -1; > >>> } > >>> [...] > >>> The issue is that when I implement this, I get an error on the > drop filter: > >>> "Failed to create rule." Do you have any idea why this might > be happening? > >> There is no this exact error text in your code or DPDK, > >> I assume we're talking about the quoted fragment. > >> `flow` is a pointer, the correct error condition is `if (flow > == NULL)`, > >> so your code probably misinterprets success as error. > >> Also `flow` is not assigned if `rte_flow_validate()` returns non-0. > > -- > Regards, > Vladimir > -- Regards, Vladimir --------------Mo21uRIqPVND16llvnyKk8Eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

You can also try with the existing X540-AT2 NIC the following :

- Init NIC with 2 queues

- set the FDIR flow for your particular ip/port to route your packet to a queue number, say 1

- Instead of using rte_flow to drop all other packets, use RSS. Rewrite the RSS ReTa (see rte_eth_dev_rss_reta_update) with queue id you are not going to poll, so in this case with queue id = 0. All ReTa entries will be 0, so packets not matched with the FDIR will be assigned to this queue.

- ignore rx on the queue 0

I believe this approach would be better for your particular use case, than relying on rte_flow to drop all the traffic, which, as we could see, depends on the internal HW implementation.

On 04/02/2025 15:50, Sid ali cherrati wrote:

Hello Vladimir,

Thank you for the clarification.

I'll try using the E810 and provide an update on the issue.

Best regards,
Ali


Le mar. 4 févr. 2025 à 16:41, Medvedkin, Vladimir <vladimir.medvedkin@intel.com> a écrit :
Hi all,

The goal that Ali is trying to achieve is not possible with the X540-AT2
NIC (as with any other ixgbe NIC). The problem is related to:

1. The first rule is processed by the FDIR engine

2. FDIR engine is executed in the HW pipeline almost in the end (just
before RSS), i.e. after other filters that we could use to match all
other packets (5tuple filter engine in this particular case).

Therefore my recommendations here would be to use a modern NIC such as
E810 to implement the required filtering logic.

On 04/02/2025 09:28, Dariusz Sosnowski wrote:
> Hi,
>
> Anatoly, Vladimir - Would you be able to help with the issue regarding DROP action not being supported on X540-AT2?
>
> Best regards,
> Dariusz Sosnowski
>
>> From: Sid ali cherrati <scherrati1@gmail.com>
>> Sent: Monday, February 3, 2025 18:12
>> To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
>> Cc: users@dpdk.org
>> Subject: Re: DPDK Flow Filtering Not Working as Expected
>>
>> External email: Use caution opening links or attachments
>>
>> Here is a better version of the code :
>>
<snip>
>>
>> Le lun. 3 févr. 2025 à 16:00, Dmitry Kozlyuk <mailto:dmitry.kozliuk@gmail.com> a écrit :
>> 2025-02-03 14:51 (UTC+0100), Sid ali cherrati:
>>> [...]
>>> if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)){
>>> flow = rte_flow_create(port_id, &attr, pattern, actions, &error);
>>> }
>>>
>>> if(flow != 0){
>>> printf("Filed to create drop flow filter \n");
>>> return -1;
>>> }
>>> [...]
>>> The issue is that when I implement this, I get an error on the drop filter:
>>> "Failed to create rule." Do you have any idea why this might be happening?
>> There is no this exact error text in your code or DPDK,
>> I assume we're talking about the quoted fragment.
>> `flow` is a pointer, the correct error condition is `if (flow == NULL)`,
>> so your code probably misinterprets success as error.
>> Also `flow` is not assigned if `rte_flow_validate()` returns non-0.

--
Regards,
Vladimir

-- 
Regards,
Vladimir
--------------Mo21uRIqPVND16llvnyKk8Eb--