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 A392AA0548 for ; Fri, 12 Nov 2021 10:34:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7C31C410EA; Fri, 12 Nov 2021 10:34:19 +0100 (CET) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60097.outbound.protection.outlook.com [40.107.6.97]) by mails.dpdk.org (Postfix) with ESMTP id 5248140692 for ; Fri, 12 Nov 2021 10:34:18 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i+04z0FQmfpU1kaHrUjzO6bWpqD15ksfrCVZVaAOS+BR5Q9uy1jw4qQyDbXdb+fqH8qdr47cdkmJW7uC8cmo/nlBz0lFdUjVHBDvoX0EMCRYDtWCP9iGw/f3L9Fi4mQCimhR9WP6LQbhSqEn0QBdtbtmUs03GVVGYW+oHdZAorBs4RMMU3HRso+3nTJUosqQKzzkSClBFLcF+Us84AcAk38/QC6YiA8Ur1KWxS6jx59EWA0FYskMNe48Zoywxc/oQQx+Y8JdTLFe/f2J6h4DlwQxHvikzivXN9o2Qy1PaW/e7lDae8RVSs9BJlkndRN7xVcdhnbECpzvRhLs4U6GMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=w/FsOlzhr6IjEmE7yQKJQTLgEU5PjHzB438BQ2EaCbY=; b=f67n450bGmWedWLXLg7Fyh6pzx8bdyB/09QUvh2VM9JGVmztqW4CFso+Hz9EGUJ0cWlMhZ9MYQ2ooYIhMB1ydOeaAD7wZYVWuWmGFpJmThgwGkO7mgc8omXoc7sw7Zbj3gb7oWTvGPtv7dmbOVP9F+gg5Iax8epBLTCUUuUZJUaitZDU5ykMMEuDo+0JJmnJ/3gS1mRKvWgN54+Pyu5ffzHt16Pvj51+RFkK4xQLYdglQotFDIFnLn4DMKCxp2spIKgkRG8Xp7ji50JciASAV6mzS/LzC7UY5QFPhqjXGqjODh9rmipTwv0uHW0DdIjbaYZsl/8OgZVpVD1zM31U9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w/FsOlzhr6IjEmE7yQKJQTLgEU5PjHzB438BQ2EaCbY=; b=M4i4lgFCEVxCwEAqD4BsOnds3+zZVwuSjEps5Edj6eEs/hDuDRJHaefNiT/JhTVgch8MDsh0waYWMBnZQTK1YlZPLdb69i1aFpDgwizK6a/PU8ldwHR14gT8s0WXraEsaGlSfeagk6bLP3qGtnwJStHplyrkkIUro3Pw5CvMOgI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uclouvain.be; Received: from AM9PR03MB7632.eurprd03.prod.outlook.com (2603:10a6:20b:413::19) by AM9PR03MB7695.eurprd03.prod.outlook.com (2603:10a6:20b:41f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Fri, 12 Nov 2021 09:34:17 +0000 Received: from AM9PR03MB7632.eurprd03.prod.outlook.com ([fe80::3031:cf2d:5c9f:65e]) by AM9PR03MB7632.eurprd03.prod.outlook.com ([fe80::3031:cf2d:5c9f:65e%8]) with mapi id 15.20.4690.015; Fri, 12 Nov 2021 09:34:17 +0000 Content-Type: multipart/alternative; boundary="------------SlgvCn8GTiXRmsPLDfg0LGfS" Message-ID: Date: Fri, 12 Nov 2021 10:34:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: rte_flow MARK + JUMP with mlx5 Content-Language: en-US To: Daniel Romell , "users@dpdk.org" Cc: "orika@nvidia.com" , "andrew.rybchenko@oktetlabs.ru" , "barbette@kth.se" References: From: Tom Barbette In-Reply-To: X-ClientProxiedBy: AM0PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:208:136::32) To AM9PR03MB7632.eurprd03.prod.outlook.com (2603:10a6:20b:413::19) MIME-Version: 1.0 Received: from [IPV6:2001:6a8:308f:2:ada4:862:8e65:6345] (2001:6a8:308f:2:ada4:862:8e65:6345) by AM0PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:208:136::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.19 via Frontend Transport; Fri, 12 Nov 2021 09:34:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c51817f4-9b1b-4812-dc47-08d9a5bf98a9 X-MS-TrafficTypeDiagnostic: AM9PR03MB7695: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: w9sMELd4Xo/okUUNIBu6vS7ZE/kydYvPNuukcS1GlgHIgH2FZKbQD1NdhWpp7FYkLoUkuoy2qIRgSHLkYriXP7mPOlwavKONKRkbFaOEEz2OSbbA22e4alDsq/Q1AuBzHXgkTB6aK59xh7nBldR0dkt7yWEc/QuBTq0uwpPvLmcDnyzThjsP9twhy4d7aihVDbJr0s1KodSxBNg5PT724kXSLdfhPQ48oYe+882nlZ/pkce0m+AfK2h2zeIpdJvE6dY7uSfV5V9fBXtNAKdoLMeUTbt2qLEsOdkAwHBz9pCBrAOK1XR83i5d8kg/FOkxn9t/EbHPMxbI59luwvzuqNuImH7FiG3bX0sh7qPhnDA/K9AgMm62B5/csT9WFqmluwrm/oXRYm5fmny8+KZkY82XcJjaV2otZ0fQ0IXNjaX6kzWK66SuzCkF+2DRpUaqTazZiGQKm44sLz0oJs8ok+j8eAHX6uf3MMgZda0pxcH3+b9NKAu6utB/CFWoCENu1AQsqbSYmO3g/H4qvGApXiNKRuHJMnJ9fn51aV/XR0af9AEZLizK5zAD1vlF2prgMWDf1MetmTGcunHEgnqayX24be7lWJnFJLJD060Z/MoGOqvA5ukRI4me3u+sE9V7cl13o1xKwGDqfXpnOGPRIi85nir5XOp7uuKZKpMmuktzMkAAJBacfAE3l6tSG2sje3jQZhwpqOgsxZx2yONiM4OFSXDLcHxYusi92VSY2yfrtPROQ/JvS0vT2GaZlqt3zpmwARY63RpXGqJWuHytuHIsPw6xPlwMD/1lnuQTwgJrWEte8vr0CxAidinR1cEN X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR03MB7632.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(186003)(83380400001)(33964004)(66574015)(66476007)(1015004)(2616005)(786003)(31686004)(4326008)(8936002)(508600001)(86362001)(110136005)(66556008)(66946007)(52116002)(166002)(45080400002)(966005)(2906002)(5660300002)(316002)(44832011)(31696002)(36756003)(19627405001)(54906003)(6486002)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?akRPYUo2a3NqS3pua0F2b1ZqSEJSeDNXZWRvMkJRNVREV3U4QVR4ZklDTDUz?= =?utf-8?B?Tm1qWHhua20yQXVJWi9kYktLSlRSckNyK0RBSHZxVDlmbmEvRUtBOEdJRmp4?= =?utf-8?B?WkZJNEFEdHgyMzFNOTBNRlNtbkVqc05xRnBDRG5CbS9EZzdHaGsrTk5sNmx5?= =?utf-8?B?WlpSL2dyMEthNEFsRTRNUXZMQndHcXJNcllUK1paZzdkTitCandyZnovWEI3?= =?utf-8?B?RERNZEprdlZWZHRodmErNnB3OEVHTTlhZ3FLcWJVYUcrcEVRK29NdlFVemRS?= =?utf-8?B?ZlNsZlV0aUx1Yk50bzhUZE51dG10QkRKTDJvVkk3VW1MT3FHS2ZGTURwMTc1?= =?utf-8?B?UVBKQVErdEJUYnRVdUg2NXRSSU1MaWwrb1hBNTBCcSttanVuaGZ5MzlpeVdY?= =?utf-8?B?bm84U3FXN1V3NVVyeGNCUnRqRjlibHdtSTFBUHhTSXdPOXgwSkdHZ1pMUzhC?= =?utf-8?B?YWNyei9hczFhZ2FPMUdjc0N5SHlpNXRNNzNubFRWbTV3U3RCWXoxSWlVYTlh?= =?utf-8?B?UStFQmQvYUF5M09lOGlZaFIwSFFYVVpaMnp6UCtEdVEzcThpZ1pGSFFXREd1?= =?utf-8?B?SmJXL1JyazRFeXAvUGdJbmVtKzlhYk1VeWtNRThsWnoxR2RqbnpVUGlDZFM4?= =?utf-8?B?WXBnUEljcjUxQmdxL3I2SGNIekZ4TnF1QjhJSktjVXZuMS9YNWZwT3RLbklG?= =?utf-8?B?blUzR3RYUitpVTNUWGRVRGlidnpCLzlGTzV2dGpqUDNuS1hYM2tjNG9ET2hS?= =?utf-8?B?Y0lneDJwMzRBbkhlWkxBaThlRkJORkpXV2hiRGRJSkNlLzIyN3Bra3RaaVg5?= =?utf-8?B?ZDVYcjdUL0NLU01SS3JTeTcxcUFuakRFOWIrUjNFUjF4TXZnbE55TnNqUktB?= =?utf-8?B?b2cvQnFJYU5NcEV1N3I4RzRkSTlaM05xUnIveXViWWFyWUpnbHRwQ0lUeE16?= =?utf-8?B?QkV6Z3dLWDFlcWUyQjlBRHh2azlZZVpsOENtT1BNZ0w0eXlKOHlQb3ZiZmhr?= =?utf-8?B?UlcwV1I2K04yakNQY1BpM0FENzNOVlAwTkFBNlROVVRSNVpkTzlzQVAwbGE4?= =?utf-8?B?WU5SNytPRHFVWWFMZGR4K0FXM3pUQ1hneTFPVGNVZ0k0TGhCRXVtL2I2VWxj?= =?utf-8?B?MmhUWHArT25ZVHk0NWkvUUVYci81ZGtKRHl2UktpSDRWcTlDWHdSK3hUWlFv?= =?utf-8?B?b293TlZIM2RoSjNhTUhoZXdEN2NrK2FTYmNVNzRVamFCV2ZZWDlvdU80SXM1?= =?utf-8?B?bW1oOWtKRDRqMHB0V1VkTkxKZVZ3Z2REUEdRMmNuSEFrbmRaQkxUMXVkcVps?= =?utf-8?B?Y0NKUnhsSE9vaXorUm13L24yeXc0bWRBMWpIamgyQzhMYm0vYW5ZbFVYbU5H?= =?utf-8?B?b04wQldjQXhxMFFldDM0eWFCVG8vTGNMRHVwejBUV2UrWnVwcHAvOFgrYmov?= =?utf-8?B?UU4vaEFjSHNyemU2V0ttQ3JaN1hBZ1FwRTNZb014UmR3eFU4Z1dYWisrdmRj?= =?utf-8?B?WlFHbGVZNDFNblZlZTJxOGxoMXUvZklLeHZpM2JEWXV3eHNNczQyajI1MHRw?= =?utf-8?B?QlZKV21JN1lya0xIaFBYQUNrZkpwWXBHR3JHc2V3L2xhQTdmNUtRZzJKc2FX?= =?utf-8?B?T0FhbGJEdEI5ZHV1R0FraUNGSjBSQjZxY2NncGt4djhJQXN4SW9JVFppcjNk?= =?utf-8?B?RC9Ob0FsWjRmdEFhbTh6ZDJ6MXVxZ1NjNEFYajFOaXN1QnR5UHJhaThEZndT?= =?utf-8?B?YTd0OWViSmR0S0JSYmNMc1JqbnlsRzR2SnVpUVlyL0lHWTNGUUpkRERWVWhE?= =?utf-8?B?RXRoMXU0K2ZBTkI0UTJRUVFkTW1WSGtMaFBTTmROdzB2WFVVZ3V1WEhlN3NW?= =?utf-8?B?azVxenJpU25Ld3RmYytNR0NIazNyNE1MamFzVjJwUk11UkxEYUVubWV6bU84?= =?utf-8?B?Q0QwbFpkQjJEbDlidTBkQ3paMVpLdFRxM2FMN0lxYzJ1YzRrMktUU3A3N05I?= =?utf-8?B?T1FCQWZMNXF6V2J1ekMxcUJHcXdxNmdVaHFpWWt1dXJhQi80SGxFR08zWjRE?= =?utf-8?B?M0xYMXpFTjRySEo0Nk9ZSVJmTWszNDNrcXl2ajNDVFhrK2VuUEhvR245NElM?= =?utf-8?B?Y0tSV3ZNcXdVVUVROUV0ZWQwVTNvQ29ncTRLeVY0Z01Sek0xNlo3RVU4K2c4?= =?utf-8?B?dnpQZzArSkJrNVJQL1V4NE1xdU5mdWRXVkpwLy9hVmM2T3hGR2F2MlpwM0pG?= =?utf-8?B?MlZmV2JlQUo5R2IzZGVBbVR4bFVBeUplVDBzM0xTSWFhemdvZWtCcFBPNzdn?= =?utf-8?B?eVQ2NjRtMHJYTjVaVjFsMStxejhaMnF0dk1NYzZDK2JxSDBlRHJmUT09?= X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-Network-Message-Id: c51817f4-9b1b-4812-dc47-08d9a5bf98a9 X-MS-Exchange-CrossTenant-AuthSource: AM9PR03MB7632.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2021 09:34:17.0491 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qOFehiKsnWQM1PeeUfhNu1gUsPa6Zdq9q/sUo21Eb6iffgj7VbEtPu559y63PTdMKH8dpBZvkqtJVNZxY13P40gj+RbLFXrTE+bGnvihAyM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7695 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 Archived-At: List-Archive: --------------SlgvCn8GTiXRmsPLDfg0LGfS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 11-11-21 à 13:48, Daniel Romell a écrit : > Hey all! > > A few questions about rte_flow, specifically the MARK + JUMP actions; > > What's the expected behavior of MARK + JUMP in the same flow? Is the > mark expected to survive to the target flow group? Is it driver > specific? Undefined? Unsupported? > > For example, when testing with the following flow setup in testpmd > (mlx CX6, DPDK 19.11.2 and latest mainline), none of the received > packets are marked: > > flow create 0 ingress pattern eth / end actions mark id 0x1337 / jump > group 1 / end > flow create 0 ingress group 1 pattern eth / end actions queue index 0 > / end > > A single flow with MARK + QUEUE works as expected. I don't know about that, I would have expected it to work. > > What I want in the end is a set of simple RSS rules that would match > most of the traffic, and another set of rules that would mark a small > subset of the traffic before being processed by the RSS rule. > > I realize I *could* duplicate the RSS actions and have them in the > same rule as the MARK, but that just seems like the wrong thing to do > for a few different reasons; > * It would require one flow for each combination of MARK and RSS > condition. > * The MARK rules should be inserted and removed during runtime, while > the RSS rules should be long-lived and static. > * The code inserting the MARK rule ideally shouldn't have be aware of > the RSS config (other than that it should continue to a new group for > further matching). As far as I know, and from that discussion you mention, there is no "go back to the default global RSS action" action. Once you add a rule, you have to add the RSS fate action. You can duplicate the "global" RSS using rte_eth_dev_rss_hash_conf_get only once with the new "shared action" API  (    rte_flow_action_handle_create etc) precisely to avoid creating many RSS context as you mentioned. Tom > > What's the right way of doing something like this with DPDK? > I've already implemented the same thing with a custom/proprietary mlx > driver, so I know it should be doable. What I ended up doing there was > simply to have two flow tables. The root table (level 0) holds all > "mark" rules (flow tag), and forwards to everything (including misses) > to the next table. The table at level 1 contains the RSS rules, and > leaves all flows untagged so the tag set in the first level is > preserved. Is there a way to get to a similar setup through the > rte_flow API? > > Thanks, > Daniel Romell > > (CCs as suggested by Thomas in slack + Tom as this seems somewhat > similar to https://www.mail-archive.com/users@dpdk.org/msg03900.html > ) > > *Disclaimer:* > This communication (including any attachments) is intended for the use > of the intended recipient(s) only and may contain information that is > considered confidential, proprietary, sensitive and/or otherwise > legally protected. Any unauthorized use or dissemination of this > communication is strictly prohibited. If you have received this > communication in error, please immediately notify the sender by return > e-mail message and delete all copies of the original communication. > Thank you for your cooperation. > --------------SlgvCn8GTiXRmsPLDfg0LGfS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Le 11-11-21 à 13:48, Daniel Romell a écrit :
Hey all!

A few questions about rte_flow, specifically the MARK + JUMP actions;

What's the expected behavior of MARK + JUMP in the same flow? Is the mark expected to survive to the target flow group? Is it driver specific? Undefined? Unsupported?

For example, when testing with the following flow setup in testpmd (mlx CX6, DPDK 19.11.2 and latest mainline), none of the received packets are marked:

flow create 0 ingress pattern eth / end actions mark id 0x1337 / jump group 1 / end
flow create 0 ingress group 1 pattern eth / end actions queue index 0 / end

A single flow with MARK + QUEUE works as expected.
I don't know about that, I would have expected it to work.

What I want in the end is a set of simple RSS rules that would match most of the traffic, and another set of rules that would mark a small subset of the traffic before being processed by the RSS rule.

I realize I *could* duplicate the RSS actions and have them in the same rule as the MARK, but that just seems like the wrong thing to do for a few different reasons;
* It would require one flow for each combination of MARK and RSS condition.
* The MARK rules should be inserted and removed during runtime, while the RSS rules should be long-lived and static.
* The code inserting the MARK rule ideally shouldn't have be aware of the RSS config (other than that it should continue to a new group for further matching).


As far as I know, and from that discussion you mention, there is no "go back to the default global RSS action" action. Once you add a rule, you have to add the RSS fate action.


You can duplicate the "global" RSS using rte_eth_dev_rss_hash_conf_get only once with the new "shared action" API  (    rte_flow_action_handle_create etc) precisely to avoid creating many RSS context as you mentioned.


Tom


What's the right way of doing something like this with DPDK?
I've already implemented the same thing with a custom/proprietary mlx driver, so I know it should be doable. What I ended up doing there was simply to have two flow tables. The root table (level 0) holds all "mark" rules (flow tag), and forwards to everything (including misses) to the next table. The table at level 1 contains the RSS rules, and leaves all flows untagged so the tag set in the first level is preserved. Is there a way to get to a similar setup through the rte_flow API?

Thanks,
Daniel Romell

(CCs as suggested by Thomas in slack + Tom as this seems somewhat similar to https://www.mail-archive.com/users@dpdk.org/msg03900.html)

Disclaimer:
This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is considered confidential, proprietary, sensitive and/or otherwise legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.

--------------SlgvCn8GTiXRmsPLDfg0LGfS--