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 A2C6043D05 for ; Wed, 20 Mar 2024 16:19:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0EE3A40ED3; Wed, 20 Mar 2024 16:19:17 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04olkn2039.outbound.protection.outlook.com [40.92.73.39]) by mails.dpdk.org (Postfix) with ESMTP id 319AB402B9 for ; Wed, 20 Mar 2024 16:19:15 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cU2uZ6HhhZw6bC6jl9KbG9uT6MC5qSNd7pgtq8E/84izQn5bBq0nGuTlKcwBm5wF9ia9h2MBOEZR5gpatnVsxHzLbGzh7iuadluXcGaeuXzeE642ELqtlXnLEtyYGjWxHv2/d1SyFQX3tSMR17nPfimPbViUzzpTV8WsVjLyDVQP53lf4XUGVez2SjsspAfc26vd1SD/NTkVRGi9ruvHkKAe7DSkCCGQ1W1m56o50IasvuGJvLMfjWSz/zS7k4mym8yA0N7oEVqgaMWnovdoWojWm49eCXy+ntyfFQZ5sscAAntSZPTa/LQFa9XioysaZAxU0mVqSf9GOr+bHabVBA== 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=aK+T6/5esjtusXibDL8xPAW5aZvPGD5tEmxUV9IJJZk=; b=DAnvyNVDC/N+CWjb/nUS7bfYRrSnJFoeDVkCvPWJVvHxAhmuPQYqYJoSCAwiGYZ8R8j4n7eLJkoUtKn5sZ3gJI59OGeAkpiRO3EUR6XI2gKam5hsLfX9xrFleiJnmXrMt+kTAXiQCrF9hOpOyw3X9NFe5r82X8N3HfaoVqV1oETgZEih3YgzxpinPUiYhbUzoDM8LasTcNKheXUdATPLdz3SX5hIq+4AYNL6pcpROKQHH8nBhDPzEpxKrFMLMR8RY1h5Vq3wk2GP5lInf14ZvXjSST/1vMSm0/j7Ihb713UOL/2FEpXJuXjdj7jDnn6WNODh/vXpFTS2GKmp7Gos/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aK+T6/5esjtusXibDL8xPAW5aZvPGD5tEmxUV9IJJZk=; b=r+9l4XU4LfipoXjmk28QBE1UPJnoFCo/2joaeaIYU61ZD8qpcL7Rz/zfJkxX9Mp39xpr7kIY83Yo4OPOQs5KQtfTYGFZfpra4HvoJGkTWhgYPZvvA+G/pTA1q0dWmk8HWKbiBzitk2S0sqnQuIqOUouNWRHjA0/Sij9Oal+22QnJsieEh+jCCH66UQ4KOXacjPMEmWv5R+YSgYjpCPu5WiZ5E6bfiNdQ/TyDQWOHc59OWpl98u8L0n91fXvDvKBq81AR5UlE2p8HfvNWADXCSxxwVbOCt2IjGNSejYANqB3rD+byDv6nAeg9kB9V2gY6HmlHHuINqBhVtx9jBLfW8g== Received: from DB9P193MB1739.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:24f::20) by AM8P193MB1012.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:1e8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Wed, 20 Mar 2024 15:19:13 +0000 Received: from DB9P193MB1739.EURP193.PROD.OUTLOOK.COM ([fe80::181b:48ce:3f89:e0da]) by DB9P193MB1739.EURP193.PROD.OUTLOOK.COM ([fe80::181b:48ce:3f89:e0da%7]) with mapi id 15.20.7386.030; Wed, 20 Mar 2024 15:19:13 +0000 From: Tao Li To: Gregory Etelson , "suanmingm@nvidia.com" , "guvenc.gulce@gmail.com" , "users@dpdk.org" Subject: Re: mlx5: rte_flow template/async API raw_encap validation bug ? Thread-Topic: mlx5: rte_flow template/async API raw_encap validation bug ? Thread-Index: AQHaeR69jTMrzstfekO6fNfTJZmSdbE+NUeAgADrGQCAAZmltA== Date: Wed, 20 Mar 2024 15:19:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [PaSsot0ymXTng8PfMG5yVJZNrCrr8I5K] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9P193MB1739:EE_|AM8P193MB1012:EE_ x-ms-office365-filtering-correlation-id: 54d1acc7-a677-4b0a-fc96-08dc48f119ab x-ms-exchange-slblob-mailprops: 02NmSoc12Dcg1phQDVDszlrp2eEa7o2Td6F/LGCQdiRbBe7SKohQwM/d9NWTi45A6gv8PcC8J4uknzDozvrZPIq1GsV3Iyfsde6t4u/wYgy8qW+4OyrsboHUl3t4tti5hb2R0Yu+2EHkS20zGLaHwz99K+aAXsOPkCzjUZyQetjpK0w3tuZ0hYjI2faw8F4RFlSIodfgKmOhWhGpqEvx5mTMxUEp0GK3cuBzQPjylFmShKGYilTf3eJEfCCZI7mOjfznAGQClgDeflz3Hlwk1gdj8cZPhiEvG96ILOxi8ZeFvlDL0buzGkkF+nserNH4mWdWAgpEzIdRfhUDKT5LKnxDRK34xEUUPuF3piKPTMxVqwQFCFrBpJCoL12xPhw+0xMrSYa/LAWCt8d4TPjWT5jQdqAl/zeMMufYVMXQZIzMgpLNgUGMTMhowtyr5Jfo3kLzh3rwhfrfSSKKbUCOjDfXBaKTQsUkTekpiU9O8Lp20vTRsAZyXihBuLs68wL05caZawtbbn7v4BnqRFwW/xNdnicgW6K3TuYxGVXhzBsKMwqEvCo0YwPvdp7BgszQj+5jNhKVHgrS2gbpfUIox0PKDgycMTHGQ/45LF2xF7C8D5Y8qvp6McedE8NQtysBiB8j4EG+rPgtA10oLJIbK+2PP1RtGSRFZ7EFtILYu7kdJlD9eEQ0XlbTXuCsbDX3kmkQJ39KLIXBoeCW8JD4KMBhaydo8SiKexgWT5dQmiJC2j7Z+kIVbtKi/jNezwbb x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dbf8Cjwq4HPoKjSBq5VSbrB4YZKpq+jeyVE780C/rvaOz9hho9bDaJOJg2VvnQvEBrLvDZxnIJmgdGnykiCWgfAwDJ2l2iNJnhpzJsKcy/XoTP8FPZpF2QDftKIctgPyZ6Fqsw5JL0RBrWQmg5KW6rG5GFSuPFM94HtpVfCnhE/n4wdn3len46WqEiuV3Z1rtg2CZWCblfthx+MbY+KIF/E1SDxQNU8aTqc6uts+8uTVYPhGEgOlqDIkb1mD7Vq8jZfztiXm5wwO/zBVH7rx8f1aSslmmJ4hXRrErM2lcXbbj1gqsX0l8u5IXDJPfzoeSPwXUnEqB6Oy30UMEKiCppnLvt6BaXLHLvJfEWHOVv1ZaQxozwXidBfVwiUAmabPfwgYQcRpisxYZXIp6gyDhWzHdzNlNQh4ur/ObYLLrcCTWjGwTV+DoGTXyI2U9qKf/fZ27NRUE6y/y3WJ5v3RCLYuaY9vJOgSzm3aUlcUAA0GRTjnLxZr6KKQRHy3o3WHVU1SOKeqLBCJS5HH8YtQ2YLJ66ar0WTbxndYGTaC4gmDcLRD7GQZMXSsRhasTqSL x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?b8Iqjyh9mV3HIsgPZQOFdQlGuI4TbVBMqKoxMTscttByFH6xYDqkFHvp?= =?Windows-1252?Q?AnMBxvj/4uwoBZBI9FQh5Yb/Vx4vkRUwrYpvZrkNrUdY2LKly6hXi/UM?= =?Windows-1252?Q?by++12Q02UPBJREdCgQl130FAtk4bACSywQhMramph8kdUHl5iGxOd8f?= =?Windows-1252?Q?ugg9VGnOAsHbsH98sz8BYIOa1x2CHJEhXoNExyqJThLzoPol5vaNfOoh?= =?Windows-1252?Q?07rI8RLcfWwtUKGZIzD6lZG8LkKRTjMKNQd0rQxpX79aemnA1QYBhJRb?= =?Windows-1252?Q?maLXU8MwIwQGSlCFZy/99upvM7z8EcG5+sOzlI7vbUE/nxFLn3qBC6Ac?= =?Windows-1252?Q?qDos6EThhvc1+jGdHCMfgHUMPi0+oF65iQ2W58nyZzpFL+7U18j26q2m?= =?Windows-1252?Q?GWySqlX7OuD8J/q45j2KoReGRmuqXV3nyJ+19Gg7qjdwqiR+MhMu0cyu?= =?Windows-1252?Q?hUrj2K9kjNWbDNUBO977r+xp+9UgHTNYK3TGelRuFyETEKxtyXv0aYwz?= =?Windows-1252?Q?MWa6HIjqvBor+VNYbWZ/yP5YUj/37dygioxwr/emcYisgpE6XF41BrcD?= =?Windows-1252?Q?LBvOnMD/Xey5jjdgP6HUfR5vNbN3QcwjF2zi9Iqdr0dENttDYfgw9FF/?= =?Windows-1252?Q?i15eRf/aG1QuBVtZjAgGVKVENnKO63d7MWc51IWWq/G/r38vYapNzZ3w?= =?Windows-1252?Q?JRqDazcg3wun2r+bN4vOlwpXuKkfEBPsUmfBeqIhfc7bInprDecscRwG?= =?Windows-1252?Q?BkR12NMZf/Am+S2EPi+4rbauGns0LomMS0qU03a/ODIgYo/Kw+2FhgwB?= =?Windows-1252?Q?oEV0Ph3nXEZBQZz76PhOteaW48enJyuS8NfDGGEtctanHHxMTTSzT1Ut?= =?Windows-1252?Q?nZtILUrRs1aXJnqPHLHgGdL4Er77Y9e/jDk47tko7bXoewe2x5rEQu+q?= =?Windows-1252?Q?5BORkh5kTxe6EQsQORjS9w1l7vC8z/nTYHZl5BtUV/qUymIvvLwwRoFF?= =?Windows-1252?Q?cMIyLaDgli+f0i0NxpgAQBUetkxftoQL+mST9oYRVlQKVA2GO+qp/KG5?= =?Windows-1252?Q?y0JxtPQTX4XNYhCbhyVvNcW9u+LzFhH0bK2GAOlcNDpIJUvnyrpOlPcQ?= =?Windows-1252?Q?zMHgmvkfkQMV60Rzqs1N4eIQR0jH0PjFVXDlm14iDvQLfVt2wbFRfoD+?= =?Windows-1252?Q?3DWn/AwNUn8BjIg0xJSzGNK3nQlZRCIBLlWfmk+yBsf5B+r9YAlZR76P?= =?Windows-1252?Q?3V+4V1EQk+KnwmDWKNobce0t8bxL4ctr7iRoJOlth9AiUYq3HuWAeY38?= =?Windows-1252?Q?Jw2AjJKSjpEuJlFeW6EAm0iuFujlOhzJYdENNsBG6mLMI5qI?= Content-Type: multipart/alternative; boundary="_000_DB9P193MB17391869983453A5175A3147A3332DB9P193MB1739EURP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-80ceb.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9P193MB1739.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 54d1acc7-a677-4b0a-fc96-08dc48f119ab X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2024 15:19:13.4685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P193MB1012 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 --_000_DB9P193MB17391869983453A5175A3147A3332DB9P193MB1739EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Gregory, I am the colleague from Guevenc. Thanks a lot for providing detailed explai= nation, and we appreciate your support very much. The guidance on the usage of the RAW_ENCAP mask is adopted and experimented= , which currently leads to the segmentation fault in our setup. The example= code used to create the action template and table template is as following= : // first action template struct rte_flow_action_raw_decap decap_action =3D {.size = =3D (sizeof(struct rte_ether_hdr)+sizeof(struct rte_ipv6_hdr))}; // remove = IPinIP packet=92s header struct rte_flow_action_raw_encap encap_action =3D {.data = =3D NULL, .size =3D sizeof(struct rte_ether_hdr)}; // add ether header for= VMs struct rte_flow_action act[] =3D { [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW= _DECAP, .conf =3D &decap_action}, //? [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW= _ENCAP, .conf =3D &encap_action}, //? [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REP= RESENTED_PORT,}, [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END= ,}, }; struct rte_flow_action msk[] =3D { [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW= _DECAP, .conf=3D &decap_action}, [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW= _ENCAP, .conf=3D &encap_action}, [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REP= RESENTED_PORT,}, [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END= ,}, }; port_template_info_pf.actions_templates[0] =3D create_actio= ns_template(main_eswitch_port, act, msk); // create template table port_template_info_pf.template_table =3D create_table_templ= ate(main_eswitch_port, &table_attr_pf, = (struct rte_flow_pattern_template **)&port_template_info_pf.pattern_te= mplates, MAX_NR_OF_PATTERN_TEMPLATE, = (struct rte_flow_actions_template **)&port_template_info_pf.actions_te= mplates, MAX_NR_OF_ACTION_TEMPLATE); Using gdb, the following segfault trace is captured: #0 0x00005555579bfb62 in mlx5dr_action_prepare_decap_l3_data (src=3D0x0, d= st=3D0x7fffffffb3cc "", num_of_actions=3D6) at ../drivers/net/mlx5/hws/mlx5= dr_action.c:2774 #1 0x00005555579c2136 in mlx5dr_action_handle_tunnel_l3_to_l2 (action=3D0x= 55555f089dc0, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, log_bulk_sz=3D= 1) at ../drivers/net/mlx5/hws/mlx5dr_action.c:1468 #2 0x00005555579bd56f in mlx5dr_action_create_reformat_hws (action=3D0x555= 55f089dc0, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, bulk_size=3D1) at= ../drivers/net/mlx5/hws/mlx5dr_action.c:1537 #3 0x00005555579bd0eb in mlx5dr_action_create_reformat (ctx=3D0x55555e756b= 40, reformat_type=3DMLX5DR_ACTION_TYP_REFORMAT_TNL_L3_TO_L2, num_of_hdrs=3D= 1 '\001', hdrs=3D0x7fffffffb720, log_bulk_size=3D1, flags=3D32) at ../drive= rs/net/mlx5/hws/mlx5dr_action.c:1594 #4 0x0000555557927826 in mlx5_tbl_multi_pattern_process (dev=3D0x555559167= 300 , tbl=3D0x17fdd1280, mpat=3D0x7fffffffb9c8, error=3D0x= 7fffffffd050) at ../drivers/net/mlx5/mlx5_flow_hw.c:4146 #5 0x000055555795f133 in mlx5_hw_build_template_table (dev=3D0x55555916730= 0 , nb_action_templates=3D1 '\001', action_templates=3D0x5= 55558dc1830 , at=3D0x7fffffffcf00, tbl=3D0x17fdd1= 280, error=3D0x7fffffffd050) at ../drivers/net/mlx5/mlx5_flow_hw.c:4235 #6 0x00005555579022d3 in flow_hw_table_create (dev=3D0x555559167300 , table_cfg=3D0x7fffffffdec8, item_templates=3D0x555558dc1828 , nb_item_templates=3D1 '\001', action_templates=3D0x555558dc1830 , nb_action= _templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_= flow_hw.c:4401 #7 0x00005555577f89ec in flow_hw_template_table_create (dev=3D0x5555591673= 00 , attr=3D0x5555589cc1e4 , item_templates= =3D0x555558dc1828 , nb_item_templates=3D1 '\001', action_templates=3D0x555558dc1830 , nb_action= _templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_= flow_hw.c:4589 #8 0x0000555556ca21e8 in mlx5_flow_table_create (dev=3D0x555559167300 , attr=3D0x5555589cc1e4 , item_templates=3D0x55= 5558dc1828 , nb_item_templates=3D1 '\001', action_templates=3D0x555558dc1830 , nb_action= _templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_= flow.c:9357 #9 0x0000555555c07c9a in rte_flow_template_table_create (port_id=3D0, tabl= e_attr=3D0x5555589cc1e4 , pattern_templates=3D0x555558dc1828= , nb_pattern_templates=3D1 '\001', actions_templates=3D0x555558dc1830 , nb_actio= ns_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../lib/ethdev/rte_flow.= c:1928 Any comment or suggestions on this issue would be appreciated. Thanks in ad= vance. Best regards, Tao Li ________________________________ From: Gregory Etelson Sent: 19 March 2024 14:25 To: Suanming Mou ; Guvenc Gulce ; users@dpdk.org Cc: Ori Kam ; Maayan Kashani Subject: Re: mlx5: rte_flow template/async API raw_encap validation bug ? Hello Guvenc, Flow actions in MLX5 PMD actions template are translated according to these= general rules: 1. If flow action configuration in template mask was not NULL, PMD const= ructs the action according to the action configuration parameters. PMD will use that pre-build action during async flow creation. The action parameters cannot be changed during async flow creation. 1. If flow action configuration in template mask was NULL, PMD ignores t= he action configuration in the template. The action will be constructed according to configuration data provided dur= ing async flow creation. Before patch 2e543b6f18a2 ("net/mlx5: reuse reformat and modify actions in = a table") the PMD ignored the RAW_ENCAP NULL mask configuration and used the action c= onfiguration for construction. 2e543b6f18a2 does not allow access to RAW_ENCAP configuration if the action= did not provide correct mask. If flow action configuration has several parameters, the action template ca= n be partially translated - some action parameters will be provided with the template and other with as= ync flow. In that case, if the action mask parameter has any non-zero value, it's con= figuration parameter will be used in a template. If the action mask parameter is 0, that parameter value will be provided du= ring async flow. Partial action translation used for pre-defined flow actions. MLX5 PMD requires the `size` parameter of the RAW_ENCAP action during the t= emplate action translation. The action data can be provided ether with the template action configuratio= n or with async flow. Therefore, the RAW_ENCAP template configuration can be fully masked with th= e action size and data or partially masked with size only. Regards, Gregory ________________________________ From: Suanming Mou Sent: Tuesday, March 19, 2024 02:24 To: Guvenc Gulce ; users@dpdk.org ;= Gregory Etelson Cc: Ori Kam ; Maayan Kashani Subject: RE: mlx5: rte_flow template/async API raw_encap validation bug ? Hi Guvenc, From: Guvenc Gulce Sent: Monday, March 18, 2024 6:26 PM To: users@dpdk.org Cc: Suanming Mou ; Ori Kam Subject: mlx5: rte_flow template/async API raw_encap validation bug ? Hi all, It is great that we have rte_flow async/template api integrated to mlx5 driver code and it is being established as the new standard rte_flow API. I have the following raw_encap problem when using the rte_flow async/templa= te API with mlx5 driver: - raw_encap rte_flow action template fails during validation when the actio= n mask conf is NULL but this clearly contradicts the explanation from Suanming Mou= 's commit 7f6daa490d9 which clearly states that the raw encap action mask is a= llowed to be NULL. 2. RAW encap (encap_data: raw) action conf (raw_data) a. action mask conf (not NULL) - encap_data constant. b. action mask conf (NULL) - encap_data will change. Commenting out the raw_encap validation would make it possible to create rte_flow template with null mask conf which can be concretized later on. Things seem to work after relaxing the rte_flow raw_encap validation. The change would look like: [Suanming] I guess maybe it is due to the raw_encap and raw_decap combinati= on. I added Gregory who added that code maybe can explain it better. @Grego= ry Etelson diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_h= w.c index 35f1ed7a03..3f57fd9286 100644 --- a/drivers/net/mlx5/mlx5_flow_hw.c +++ b/drivers/net/mlx5/mlx5_flow_hw.c @@ -6020,10 +6020,10 @@ flow_hw_validate_action_raw_encap(const struct rte_= flow_action *action, const struct rte_flow_action_raw_encap *mask_conf =3D mask->conf; const struct rte_flow_action_raw_encap *action_conf =3D action->con= f; - if (!mask_conf || !mask_conf->size) +/* if (!mask_conf || !mask_conf->size) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ACTION, mask, - "raw_encap: size must be masked")= ; + "raw_encap: size must be masked")= ; */ if (!action_conf || !action_conf->size) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ACTION, actio= n, But this can not be the proper solution. Please advise a solution how to ma= ke the raw_encap work with rte_flow template/async API. If relaxing the validation= is ok, I can also prepare and send a patch. Thanks in advance, Guvenc Gulce --_000_DB9P193MB17391869983453A5175A3147A3332DB9P193MB1739EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Gregory,

 =

I am the colleague from = Guevenc. Thanks a lot for providing detailed explaination, and we appreciat= e your support very much.

The guidance on the usag= e of the RAW_ENCAP mask is adopted and experimented, which currently leads = to the segmentation fault in our setup. The example code used to create the= action template and table template is as following:

&n= bsp;

<Code Excerpt>

        &nb= sp;       // first action template=

        &nb= sp;       struct rte_flow_action_raw_decap de= cap_action =3D {.size =3D (sizeof(struct rte_ether_hdr)+sizeof(struct rte_i= pv6_hdr))}; // remove IPinIP packet=92s header

        &nb= sp;       struct rte_flow_action_raw_encap en= cap_action =3D {.data =3D NULL, .size =3D sizeof(struct rte_ether_hdr)}; &n= bsp;// add ether header for VMs

 

        &nb= sp;       struct rte_flow_action act[] =3D {<= o:p>

        &nb= sp;            =            [0] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_RAW_DECAP, .conf =3D &decap_action}, //?=

        &nb= sp;            =            [1] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_RAW_ENCAP, .conf =3D &encap_action}, //?=

        &nb= sp;            =            [2] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,},

        &nb= sp;            =            [3] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_END,},

        &nb= sp;       };

 

        &nb= sp;       struct rte_flow_action msk[] =3D {<= o:p>

        &nb= sp;            =            [0] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_RAW_DECAP, .conf=3D &decap_action},

        &nb= sp;            =            [1] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_RAW_ENCAP, .conf=3D &encap_action},

        &nb= sp;            =            [2] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,},

        &nb= sp;            =            [3] =3D {.type= =3D RTE_FLOW_ACTION_TYPE_END,},

        &nb= sp;       };

 

        &nb= sp;       port_template_info_pf.actions_templ= ates[0] =3D create_actions_template(main_eswitch_port, act, msk);

 

        &nb= sp;       // create template table=

        &nb= sp;       port_template_info_pf.template_tabl= e =3D create_table_template(main_eswitch_port, &table_attr_pf,

        &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          (struct rte_flow_pattern_t= emplate **)&port_template_info_pf.pattern_templates, MAX_NR_OF_PATTERN_= TEMPLATE,

        &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          (struct rte_flow_actions_t= emplate **)&port_template_info_pf.actions_templates, MAX_NR_OF_ACTION_T= EMPLATE);

 

</Code Excerpt>

 

Using gdb, the following segfault trace is captured:

 

<Trace Excerpt>

#0  0x00005555579bfb62 in mlx5dr_action_prepar= e_decap_l3_data (src=3D0x0, dst=3D0x7fffffffb3cc "", num_of_actio= ns=3D6) at ../drivers/net/mlx5/hws/mlx5dr_action.c:2774

#1  0x00005555579c2136 in mlx5dr_action_handle= _tunnel_l3_to_l2 (action=3D0x55555f089dc0, num_of_hdrs=3D1 '\001', hdrs=3D0= x7fffffffb720, log_bulk_sz=3D1) at ../drivers/net/mlx5/hws/mlx5dr_action.c:= 1468

#2  0x00005555579bd56f in mlx5dr_action_create= _reformat_hws (action=3D0x55555f089dc0, num_of_hdrs=3D1 '\001', hdrs=3D0x7f= ffffffb720, bulk_size=3D1) at ../drivers/net/mlx5/hws/mlx5dr_action.c:1537<= o:p>

#3  0x00005555579bd0eb in mlx5dr_action_create= _reformat (ctx=3D0x55555e756b40, reformat_type=3DMLX5DR_ACTION_TYP_REFORMAT= _TNL_L3_TO_L2, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, log_bulk_size=3D1, flags=3D32) at ../drivers/net/mlx5/hws/mlx5dr_action.c:= 1594

#4  0x0000555557927826 in mlx5_tbl_multi_patte= rn_process (dev=3D0x555559167300 <rte_eth_devices>, tbl=3D0x17fdd1280= , mpat=3D0x7fffffffb9c8, error=3D0x7fffffffd050) at ../drivers/net/mlx5/mlx= 5_flow_hw.c:4146

#5  0x000055555795f133 in mlx5_hw_build_templa= te_table (dev=3D0x555559167300 <rte_eth_devices>, nb_action_templates= =3D1 '\001', action_templates=3D0x555558dc1830 <port_template_info_pf+16= >, at=3D0x7fffffffcf00, tbl=3D0x17fdd1280, error=3D0x7fffffffd050)=

    at ../drivers/net/mlx5/mlx5_flow= _hw.c:4235

#6  0x00005555579022d3 in flow_hw_table_create= (dev=3D0x555559167300 <rte_eth_devices>, table_cfg=3D0x7fffffffdec8,= item_templates=3D0x555558dc1828 <port_template_info_pf+8>, nb_item_t= emplates=3D1 '\001',

    action_templates=3D0x555558dc183= 0 <port_template_info_pf+16>, nb_action_templates=3D1 '\001', error= =3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_flow_hw.c:4401

#7  0x00005555577f89ec in flow_hw_template_tab= le_create (dev=3D0x555559167300 <rte_eth_devices>, attr=3D0x5555589cc= 1e4 <table_attr_pf>, item_templates=3D0x555558dc1828 <port_templat= e_info_pf+8>, nb_item_templates=3D1 '\001',

    action_templates=3D0x555558dc183= 0 <port_template_info_pf+16>, nb_action_templates=3D1 '\001', error= =3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_flow_hw.c:4589

#8  0x0000555556ca21e8 in mlx5_flow_table_crea= te (dev=3D0x555559167300 <rte_eth_devices>, attr=3D0x5555589cc1e4 <= ;table_attr_pf>, item_templates=3D0x555558dc1828 <port_template_info_= pf+8>, nb_item_templates=3D1 '\001',

    action_templates=3D0x555558dc183= 0 <port_template_info_pf+16>, nb_action_templates=3D1 '\001', error= =3D0x7fffffffe0f8) at ../drivers/net/mlx5/mlx5_flow.c:9357

#9  0x0000555555c07c9a in rte_flow_template_ta= ble_create (port_id=3D0, table_attr=3D0x5555589cc1e4 <table_attr_pf>,= pattern_templates=3D0x555558dc1828 <port_template_info_pf+8>, nb_pattern_templates=3D1 '\001',

    actions_templates=3D0x555558dc18= 30 <port_template_info_pf+16>, nb_actions_templates=3D1 '\001', error= =3D0x7fffffffe0f8) at ../lib/ethdev/rte_flow.c:1928

</Trace Excerpt>

 

Any comment or suggestio= ns on this issue would be appreciated. Thanks in advance.=

 =

Best regards,=

Tao Li=

 =

From: Gregor= y Etelson <getelson@nvidia.com>
Sent: 19 March 2024 14:25
To: Suanming Mou <suanmingm@nvidia.com>; Guvenc Gulce <guve= nc.gulce@gmail.com>; users@dpdk.org <users@dpdk.org>
Cc: Ori Kam <orika@nvidia.com>; Maayan Kashani <mkashani@nv= idia.com>
Subject: Re: mlx5: rte_flow template/async API raw_encap validation = bug ?

 

Hello G= uvenc,

&n= bsp;

Flow actions in MLX5 PMD actions template are trans= lated according to these general rules:

  1. If flow action configuration in template m= ask was not NULL, PMD constructs the action according
    to the action configuration parameters.
    PMD will use that pre-build action during async flow creation.
    The action parameters cannot be changed during async flow creation.
  1. If flow action configuration in template m= ask was NULL, PMD ignores the action configuration in the template.
    The action will be constructed according to configuration data provided dur= ing async flow creation.

 &= nbsp;

Before = patch 2e543b6f18a2 ("net/mlx5: reuse reformat and modify actions in a = table")
the PMD ignored the RAW_ENCAP NULL mask configuration and used the action c= onfiguration for construction.

2e543b6f18a2&= nbsp;does not allow access to RAW_ENCAP configuration if the action did not= provide correct mask.

&n= bsp;

If flow= action configuration has several parameters, the action template can be pa= rtially translated -
some action parameters will be provided with the template and other with as= ync flow.
In that case, if the action mask parameter has any non-zero value, it's con= figuration parameter will be used in a template.
If the action mask parameter is 0, that parameter value will be provided du= ring async flow.

&n= bsp;

Partial= action translation used for pre-defined flow actions. 

&n= bsp;

MLX5 PM= D requires the `size` parameter of the RAW_ENCAP action during the template= action translation.
The action data can be provided ether with the template action configuratio= n or with async flow.

Therefo= re, the RAW_ENCAP template configuration can be fully masked with the actio= n size and data or partially masked with size only.

&n= bsp;

Regards= ,

Gregory=

&n= bsp;

&n= bsp;

From: S= uanming Mou <suanmingm@nvidia.com>
Sent: Tuesday, March 19, 2024 02:24
To: Guvenc Gulce <guvenc.gulce@gmail.com>; users@dpdk.org= <users@dpdk.org>; Gregory Etelson <getelson@nvidia.com>
Cc: Ori Kam <orika@nvidia.com>; Maayan Kashani <mkasha= ni@nvidia.com>
Subject: RE: mlx5: rte_flow template/async API raw_encap valida= tion bug ?

 

Hi Guvenc,

 

From: Guvenc Gulce <guvenc.gulce@gmail.com> Sent: Monday, March 18, 2024 6:26 PM
To: users@dpdk.org
Cc: Suanming Mou <suanmingm@nvidia.com>; Ori Kam <orik= a@nvidia.com>
Subject: mlx5: rte_flow template/async API raw_encap validation= bug ?

 

Hi all,

 

It is great that we have rte_flow async/template api integrated to mlx5=  

driver code and it is being established as the new standard rte_flow AP= I.

 

I have the following raw_encap problem when using the rte_flow async/te= mplate API 

with mlx5 driver:

- raw_encap rte_flow action template fails during validation when the a= ction mask

conf is NULL but this clearly contradicts the explanation from Suanming= Mou's 

commit 7f6daa490d9 which clearly states that the raw encap action = mask is allowed 

to be NULL.

<Excerpt from commit 7f6daa490d9>

    2. RAW encap (encap_data: raw)     

            action conf (raw_data)  =                      = ;        

                    &= nbsp;                    =                     &nbs= p;  

            a. action mask conf (not NULL= )                 <= /span>

              - encap_data constant.=                      = ;        

            b. action mask conf (NULL)&nb= sp;                     &= nbsp;                    =                     &nbs= p;                     &n= bsp;     

              - encap_data will chan= ge.

</Excerpt from commit 7f6daa490d9>

 

Commenting out the raw_encap validation would make it possible to creat= e

rte_flow template with null mask conf which can be concretized later on= . 

Things seem to work after relaxing the rte_flow raw_encap validation.

The change would look like:

 

[Suanming] I guess maybe it is due to the raw_encap and raw_decap combi= nation. I added Gregory who added that code maybe can explain it better. @Gregory Etelson

 

<Excerpt>

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_fl= ow_hw.c

index 35f1ed7a03..3f57fd9286 100644

--- a/drivers/net/mlx5/mlx5_flow_hw.c

+++ b/drivers/net/mlx5/mlx5_flow_hw.c

@@ -6020,10 +6020,10 @@ flow_hw_validate_action_raw_encap(const struct = rte_flow_action *action,

        const struct rte_flow_action_raw_encap *mas= k_conf =3D mask->conf;

        const struct rte_flow_action_raw_encap *act= ion_conf =3D action->conf;

 

-       if (!mask_conf || !mask_conf->size)=

+/*     if (!mask_conf || !mask_conf->size)

                return rte_flow= _error_set(error, EINVAL,

                    &= nbsp;                    = RTE_FLOW_ERROR_TYPE_ACTION, mask,

-                    =                      = ;"raw_encap: size must be masked");

+                    =                      = ;"raw_encap: size must be masked"); */

        if (!action_conf || !action_conf->size)<= o:p>

                return rte_flow= _error_set(error, EINVAL,

                    &= nbsp;                    = RTE_FLOW_ERROR_TYPE_ACTION, action,

</Excerpt>

 

But this can not be the proper solution. Please advise a solution how t= o make the 

raw_encap work with rte_flow template/async API. If relaxing the valida= tion is ok, I can 

also prepare and send a patch.

 

Thanks in advance,

 

Guvenc Gulce

  

--_000_DB9P193MB17391869983453A5175A3147A3332DB9P193MB1739EURP_--