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 0A3DD43D14 for ; Thu, 21 Mar 2024 10:28:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E78B5427E1; Thu, 21 Mar 2024 10:28:37 +0100 (CET) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn2084.outbound.protection.outlook.com [40.92.91.84]) by mails.dpdk.org (Postfix) with ESMTP id 2742340261 for ; Thu, 21 Mar 2024 10:28:37 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AK+PxRsyQ6IY21mBC/9m3I6qzB2N+lziXvBBWH8qDcEZ5w7bxkUG0uSZLY4L0HTtiQFUHWcBDaU4gBDHXguHda4BUxvdG6Gb1N+lKXfbRwt8nRZsEHM4ANs5jDzrEjr2gVQ7iy75hHGznyOqHTUaf0gl+GriVrqMxLrzNIj40akYcylq3YhVyKYK06Iop9xx3g4PB3nVWNskyoH4UlEWJ1jcl3EkThMBzMyOShtqU6VlTXZrQ9Ebzb1JFKOU4uG2MRQgAB6ehek5gHsycml7Xc6GA3WdgThpPZuhGMQ6P2+U9D1TwKr3bgghZEeKMHGOlm55jWEN00pzxbPN3fuheQ== 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=GLcIwFiB2uEbJZK03ypshrYTTyq54LewhNmrqo57mjg=; b=BjCgOcOp4yTNK4P3T1lNMB6EqCbzqmzo+dVbXDWBMGcFkNVlsF7z0kDD60AIWby2MnL4jRtBy6/kUfTwFl47/jeFKu+d8/NWsbTPUnQ9FxSG1ZbUSYZQbKPcfiOHvSbhEP4KJejk2ywi3zJn7iW5Z0OYqVox9JoYQ2V2qI/nV65ETHGJAzg7XVc2dF6xY4gh8N+zdQfAdopOOZL07rateCbbJVHW9gF4uUm5mclU7igGLesbF/AsjNMasnoHGfdxbwGN51QkrWmzRgRZJ1NDLWekMI9Jrx3PxWeADuvpuB78wtIqBqcpU4XW4N7ER5TckZhgIwTB0pmgFI3RGLl1kw== 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=GLcIwFiB2uEbJZK03ypshrYTTyq54LewhNmrqo57mjg=; b=DbXidM9GIwVpdXrpRGkitbeyj2Bf7+VtMZQ5h0FYeXG9Sh7YGSSmTDRZ8xTmdkd7x5YjrJ6YEckjxeepuyfBXtCI91kjOyeFTjr2qIyhGUf1oXXSHnZmYj0lzh6GO5oMgqkSbFEpiSvlav42L9LOww92AK9YKVIhumly/eDo9ZxHyGw1W6SxWIfyyv2Q0wVEs9BUWHOisdoE1XRLfuyr45EhWXaUqn7xyZYmTXpo8I/NkYPSSYnWyldvEfzAAfeW9vN823EJrU/3ppp6ZaPmVIXDBb5cCr7kK8AEyXzirttw1dXTYOgOXwiRLkfMqcc7B+tcgK/gEW0e9wQ3FIVbpA== Received: from DB9P193MB1739.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:24f::20) by AM8P193MB1218.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:365::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Thu, 21 Mar 2024 09:28:35 +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; Thu, 21 Mar 2024 09:28:35 +0000 From: Tao Li To: Gregory Etelson , "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+NUeAgADrGQCAAZmltIAAHVoAgAEaDSo= Date: Thu, 21 Mar 2024 09:28:35 +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: msip_labels: x-tmn: [mbMolGpSDG9dJTgXWgqvdTdvsplevR82] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9P193MB1739:EE_|AM8P193MB1218:EE_ x-ms-office365-filtering-correlation-id: 60c09701-b102-46c1-ae81-08dc49894855 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wLmALM32i98m3Dck09g4srcnytEE3H/VFJI1tuf1klIBgg9TWIyagcn4pfKbhsWic2KjLclzrUA9ZTK/lM25ZNRNetrCjQEiORCACJ0kFOy/I9TVQbyjeoQPdwK4Gl6dl56u+sg/U1paICqGN5ToOW/NJY9V0L7DPsSt2fpiJuQgVR04kKVMoKOadEW7d3r+o7hnb1RDdjMAweOpXDB9mSNZU66zlMkqrLLIXLgh67PSqCGF7SYGXzrYOukj0pwwnmHXf0hEBCSSwFUklNtgzQ1nhK0cLbCf6ZsganBOPYuwKyPgeOmML6a9Db7u98Q208PtqCsORqesh5VRJrYEl41mvDfOrksym7PykjL4BbXIcdwTUMxHSeJADZyigAMBj18OxpUr1Jbv/A1GssD2gDJWehp7r4fhVhRPsqc5EBQG8BkIMeQ+rFyqMCrEKGGk9tZVaKhvrVbF+XrwYG3uHnRR5oGqe69pEUefbkBbLQmJk/PMr0MjktoRhnGBQd2ESoqC/v3KdEB4jL2H8aPdrwg+u6zydV2+N9rfZazC+sgxzoovDYrVQEL4oYx5Um7j x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?xYaR02NUZIIDn/p6WO7zOWxgzNSahzvEdmqW7h2tIOcba9tE+Cq4PFQm?= =?Windows-1252?Q?cuSaDDHPkbWRgSoIFer4dPpeEceblyevlcj2zC+YAU7cWsjCb9UjG6Qv?= =?Windows-1252?Q?QISoYLdquFRwvy7G0V6J2vutRVKqgCRoo+uQDT8mxBU1OIJZ6+JWqGO8?= =?Windows-1252?Q?G+cpjZr6lmEHnnV1vFZ9qJD1dISVLzlKXTVXhp8NQKxeP2Fp3X9TRrt/?= =?Windows-1252?Q?2lfGsMKhtFFcU2rKZU2IRgFzrem0bf84r+86Yt8rYsKXvXQC4S5rcyCn?= =?Windows-1252?Q?IlW/c8NUuIFnq1Nzf3m9IRFomrlZbF1NZR9wKnw1MdG2G6a4gk39FN+f?= =?Windows-1252?Q?ApevD2kraMed42lvNreAusODjKjlpiD0HFvqOKJP4mmnv/kNnbYOVO/E?= =?Windows-1252?Q?C5aNjV+yxxOrZtvGREDBYJL5EbWVyWHYbPQmp+pWv6VWL0u2xhNRLqV8?= =?Windows-1252?Q?vfH/fRqZSAbi0/ypXuci8D9u7GYhUfCFBJO1XXQVsk3cvP4RkVzIuNZo?= =?Windows-1252?Q?5SoPDwKi3F0D4ZEdRucn5PovAdH72PK5kl/d97H/JILRfjonz5YtsC2a?= =?Windows-1252?Q?JWcOIS3T1TQ+8do4DX36y6Z/FeXvVtQTGSci4Jd2ZRM7/RFtiAe6rTxv?= =?Windows-1252?Q?3bqEtaL/xReN3Tj0osPBRvCaZzlVJM18Q9fZBDbC/VH4BcKQ3XNLFZrG?= =?Windows-1252?Q?v2xJ1ZbZIDNQoGLO5isl7CPf1tYC17aJfrlA57sRwtRbsM9ecb5cvGeL?= =?Windows-1252?Q?8sZSsL80VO4mbZrKgx6FN03o0wuA6HK5GqT12sUn5YtXru/a64f4YTmS?= =?Windows-1252?Q?XmlAyJW4c6zjd8OSWGu/Nv+VZigDifKvEHqQyaE0NJxHm/PPbve+s5d+?= =?Windows-1252?Q?A8WjpakS/iSlzcGNS0ay0DIcyiAj5jlmt1ypgof8dY4VkLPZcwEIh91G?= =?Windows-1252?Q?1GM9T+sXzzn/zZjyVUVCZjlXqF2JqPN/PxdunlaoLUiVJtjG6Bte7nOl?= =?Windows-1252?Q?HiEV22XxTxblso29LJzicJ4BqUyKNQ0lE/7j91O+/wTyolR+pyr1Slvg?= =?Windows-1252?Q?daVstdouR7d96zkZiDEciOJuyPWmb9Riol+i90zixjn7cNPWDRTFyoq4?= =?Windows-1252?Q?xiL/B3yLeBEsnEepeRYV6xlI2DtLwyQlZAlKzoeAiCsR1P1StqU24eUd?= =?Windows-1252?Q?5Ix5r9QdfBWYHeUZCvSVzVC1dpxJ8JcWRlxh3W/iBGFrwdn7JHVEo661?= =?Windows-1252?Q?GfnNJx9A5CxmsJWRGVao+6KW0ZGifTvjjT795f4pKTQ/npOTcusEjuxy?= =?Windows-1252?Q?QAe6AnH+Wm/aZvYwLKbqavOso0IPWAi2CwyeVO9s5XkRgUfr?= Content-Type: multipart/alternative; boundary="_000_DB9P193MB173996D59B99DB360545309FA3322DB9P193MB1739EURP_" 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: 60c09701-b102-46c1-ae81-08dc49894855 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2024 09:28:35.2470 (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: AM8P193MB1218 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_DB9P193MB173996D59B99DB360545309FA3322DB9P193MB1739EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Gregory, Thanks for suggesting the workaround. Looking forward to the investigation = result and the fix. Regards, Tao From: Gregory Etelson Date: Wednesday, 20. March 2024 at 17:36 To: Tao Li , Suanming Mou , gu= venc.gulce@gmail.com , users@dpdk.org Subject: Re: mlx5: rte_flow template/async API raw_encap validation bug ? Hello Tao, I reproduced the PMD crash you've described. We'll investigate it and will issue a fix shortly. In the meanwhile, I can suggest a workaround. Please consider creating actions template with the fully masked RAW_ENCAP a= ction. The fully masked RAW_ENCAP provides data and size parameters in the action = description and sets non-zero values in the action mask configuration. Testpmd commands are: dpdk-testpmd -a $PCI,dv_flow_en=3D2,representor=3Dvf\[0-1\] -- -i port stop all flow configure 0 queues_number 4 queues_size 64 flow configure 1 queues_number 4 queues_size 64 flow configure 2 queues_number 4 queues_size 64 port start all set verbose 1 set raw_decap 0 eth / ipv6 / end_set set raw_encap 0 eth src is 11:22:33:44:55:66 dst is aa:bb:cc:dd:ee:aa type = is 0x0800 has_vlan is 0 / end_set flow actions_template 0 create transfer actions_template_id 1 template raw_= decap / raw_encap index 0 / represented_port / end mask raw_decap / raw_enc= ap index 0 / represented_port / end flow pattern_template 0 create transfer pattern_template_id 1 template eth = / ipv6 / end flow template_table 0 create transfer table_id 1 group 0 priority 0 rules_n= umber 1 pattern_template 1 actions_template 1 Regards, Gregory ________________________________ From: Tao Li Sent: Wednesday, March 20, 2024 17:19 To: Gregory Etelson ; Suanming Mou ; guvenc.gulce@gmail.com ; users@dpdk.org Subject: Re: mlx5: rte_flow template/async API raw_encap validation bug ? External email: Use caution opening links or attachments 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. 2. 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_DB9P193MB173996D59B99DB360545309FA3322DB9P193MB1739EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Gregory,=

 

Thanks for suggesti= ng the workaround. Looking forward to the investigation result and the fix.=

 

Regards,=

Tao

 

From: Gregory Etelson <= ;getelson@nvidia.com>
Date: Wednesday, 20. March 2024 at 17:36
To: Tao Li <byteocean@hotmail.com>, Suanming Mou <suanmingm= @nvidia.com>, guvenc.gulce@gmail.com <guvenc.gulce@gmail.com>, use= rs@dpdk.org <users@dpdk.org>
Subject: Re: mlx5: rte_flow template/async API raw_encap validation = bug ?

Hello T= ao,

&n= bsp;

I repro= duced the PMD crash you've described.

We'll i= nvestigate it and will issue a fix shortly.

&n= bsp;

In the = meanwhile, I can suggest a workaround.

Please consider creating actions template with the = fully masked RAW_ENCAP action.
The fully masked RAW_ENCAP provides data and size parameters in the action = description and sets non-zero values in the action mask configuration.
Testpmd commands are:

dpdk-testpmd -a $PCI,dv_flow_en=3D2,representor=3Dvf\[0-1\] -- -= i

 

port stop all

flow configure 0 queues_number 4 queues_size 64

flow configure 1 queues_number 4 queues_size 64

flow configure 2 queues_number 4 queues_size 64

port start all

set verbose 1=

&nb= sp;

set raw_decap 0 eth / ipv6 / end_set

set raw_encap 0 eth src is 11:22:33:44:55:66 dst is a= a:bb:cc:dd:ee:aa type is 0x0800 has_vlan is 0 / end_set

&nb= sp;

flow actions_template 0 create transfer actions_templ= ate_id 1 template raw_decap / raw_encap index 0 / represented_port / end ma= sk raw_decap / raw_encap index 0 / represented_port / end

flow pattern_template 0 create transfer pattern_templ= ate_id 1 template eth / ipv6 / end<= o:p>

flow templa= te_table 0 create transfer table_id 1 group 0 priority 0 rules_number 1 pat= tern_template 1 actions_template 1

&n= bsp;

&n= bsp;

Regards= ,

Gregory=

&n= bsp;

From: T= ao Li <byteocean@hotmail.com>
Sent: Wednesday, March 20, 2024 17:19
To: Gregory Etelson <getelson@nvidia.com>; Suanming Mou &= lt;suanmingm@nvidia.com>; guvenc.gulce@gmail.com <guvenc.gulce@gmail.= com>; users@dpdk.org <users@dpdk.org>
Subject: Re: mlx5: rte_flow template/async API raw_encap valida= tion bug ?

 

External email: Use caution opening l= inks or attachments<= /span>

 

Hello Gregory,

 

I am the colleague from Guevenc. Thanks a lot for providing detailed ex= plaination, and we appreciate your support very much.

The guidance on the usage o= f 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 ac= tion template and table template is as following:

 

<Code E= xcerpt>

  &= nbsp;           &nbs= p; // first action template

  &= nbsp;           &nbs= p; struct rte_flow_action_raw_decap decap_action =3D {.size =3D (sizeof(str= uct rte_ether_hdr)+sizeof(struct rte_ipv6_hdr))}; // remove IPinIP packet= =92s header

  &= nbsp;           &nbs= p; struct rte_flow_action_raw_encap encap_action =3D {.data =3D NULL, .size= =3D sizeof(struct rte_ether_hdr)};  // add ether header for VMs

 =

  &= nbsp;           &nbs= p; struct rte_flow_action act[] =3D {

  &= nbsp;           &nbs= p;            &= nbsp;    [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_DECAP, = .conf =3D &decap_action}, //?

  &= nbsp;           &nbs= p;            &= nbsp;    [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_ENCAP, = .conf =3D &encap_action}, //?

  &= nbsp;           &nbs= p;            &= nbsp;    [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REPRESENTED= _PORT,},

  &= nbsp;           &nbs= p;            &= nbsp;    [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END,},

  &= nbsp;           &nbs= p; };

 =

  &= nbsp;           &nbs= p; struct rte_flow_action msk[] =3D {

  &= nbsp;           &nbs= p;            &= nbsp;    [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_DECAP, = .conf=3D &decap_action},

  &= nbsp;           &nbs= p;            &= nbsp;    [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_ENCAP, = .conf=3D &encap_action},

  &= nbsp;           &nbs= p;            &= nbsp;    [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REPRESENTED= _PORT,},

  &= nbsp;           &nbs= p;            &= nbsp;    [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END,},

  &= nbsp;           &nbs= p; };

 =

  &= nbsp;           &nbs= p; port_template_info_pf.actions_templates[0] =3D create_actions_template(m= ain_eswitch_port, act, msk);

 =

  &= nbsp;           &nbs= p; // create template table

  &= nbsp;           &nbs= p; port_template_info_pf.template_table =3D create_table_template(main_eswi= tch_port, &table_attr_pf,<= /o:p>

  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  (struct rte_flow_pattern_template **)&port_template_info_pf= .pattern_templates, MAX_NR_OF_PATTERN_TEMPLATE,

  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  (struct rte_flow_actions_template **)&port_template_info_pf= .actions_templates, MAX_NR_OF_ACTION_TEMPLATE);

 =

</Code = Excerpt>

 

Using gdb, the following segfault trace is captured:

 =

<Trace = Excerpt>

#0  0x00= 005555579bfb62 in mlx5dr_action_prepare_decap_l3_data (src=3D0x0, dst=3D0x7= fffffffb3cc "", num_of_actions=3D6) at ../drivers/net/mlx5/hws/ml= x5dr_action.c:2774

#1  0x00= 005555579c2136 in mlx5dr_action_handle_tunnel_l3_to_l2 (action=3D0x55555f08= 9dc0, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, log_bulk_sz=3D1) at ..= /drivers/net/mlx5/hws/mlx5dr_action.c:1468

#2  0x00= 005555579bd56f in mlx5dr_action_create_reformat_hws (action=3D0x55555f089dc= 0, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, bulk_size=3D1) at ../driv= ers/net/mlx5/hws/mlx5dr_action.c:1537

#3  0x00= 005555579bd0eb in mlx5dr_action_create_reformat (ctx=3D0x55555e756b40, refo= rmat_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/m= lx5/hws/mlx5dr_action.c:1594

#4  0x00= 00555557927826 in mlx5_tbl_multi_pattern_process (dev=3D0x555559167300 <= rte_eth_devices>, tbl=3D0x17fdd1280, mpat=3D0x7fffffffb9c8, error=3D0x7f= ffffffd050) at ../drivers/net/mlx5/mlx5_flow_hw.c:4146

#5  0x00= 0055555795f133 in mlx5_hw_build_template_table (dev=3D0x555559167300 <rt= e_eth_devices>, nb_action_templates=3D1 '\001', action_templates=3D0x555= 558dc1830 <port_template_info_pf+16>, at=3D0x7fffffffcf00, tbl=3D0x17= fdd1280, error=3D0x7fffffffd050)=

  &= nbsp; at ../drivers/net/mlx5/mlx5_flow_hw.c:4235

#6  0x00= 005555579022d3 in flow_hw_table_create (dev=3D0x555559167300 <rte_eth_de= vices>, table_cfg=3D0x7fffffffdec8, item_templates=3D0x555558dc1828 <= port_template_info_pf+8>, nb_item_templates=3D1 '\001',

  &= nbsp; action_templates=3D0x555558dc1830 <port_template_info_pf+16>, n= b_action_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/ml= x5/mlx5_flow_hw.c:4401

#7  0x00= 005555577f89ec in flow_hw_template_table_create (dev=3D0x555559167300 <r= te_eth_devices>, attr=3D0x5555589cc1e4 <table_attr_pf>, item_templ= ates=3D0x555558dc1828 <port_template_info_pf+8>, nb_item_templates=3D= 1 '\001',

  &= nbsp; action_templates=3D0x555558dc1830 <port_template_info_pf+16>, n= b_action_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/ml= x5/mlx5_flow_hw.c:4589

#8  0x00= 00555556ca21e8 in mlx5_flow_table_create (dev=3D0x555559167300 <rte_eth_= devices>, attr=3D0x5555589cc1e4 <table_attr_pf>, item_templates=3D= 0x555558dc1828 <port_template_info_pf+8>, nb_item_templates=3D1 '\001= ',

  &= nbsp; action_templates=3D0x555558dc1830 <port_template_info_pf+16>, n= b_action_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../drivers/net/ml= x5/mlx5_flow.c:9357

#9  0x00= 00555555c07c9a in rte_flow_template_table_create (port_id=3D0, table_attr= =3D0x5555589cc1e4 <table_attr_pf>, pattern_templates=3D0x555558dc1828= <port_template_info_pf+8>, nb_pattern_templates=3D1 '\001',

  &= nbsp; actions_templates=3D0x555558dc1830 <port_template_info_pf+16>, = nb_actions_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../lib/ethdev/r= te_flow.c:1928

</Trace= Excerpt><= /p>

 =

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

 

Best regards,

Tao Li

 

From: Gregory Etelson <g= etelson@nvidia.com>
Sent: 19 March 2024 14:25
To: Suanming Mou <suanmingm@nvidia.com>; Guvenc Gulce <= ;guvenc.gulce@gmail.com>; users@dpdk.org <users@dpdk.org>
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 ?

 

Hello Guvenc,

 

Flow actions in MLX5 PMD actions template are translated according to t= hese 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.    <= span style=3D"font-size:12.0pt">
  2. If flow action configuration in template mask 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.    =

  

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.=

2e543b6f18= a2 does not allow = access to RAW_ENCAP configuration if the action did not provide correct mas= k.

 

If flow action configuratio= n has several parameters, the action template can 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.<= /p>

 

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

 

MLX5 PMD 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.

Therefore, the RAW_ENCAP te= mplate configuration can be fully masked with the action size and data or p= artially masked with size only.

 

Regards,

Gregory

 

 

From: Suanming Mou <suan= mingm@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 <= /p>

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)  =                      = ;        <= /o:p>

                    &= nbsp;                    =                     &nbs= p;  

            a. action mask conf (not NULL= )                 

              - encap_data constant.=                      = ;        <= /o:p>

            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;<= /o:p>

 

-       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,<= o:p>

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

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

        if (!action_conf || !action_conf->size)<= /span>

                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 <= /p>

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

also prepare and send a patch.<= o:p>

 

Thanks in advance,

 

Guvenc Gulce<= /p>

  <= /p>

--_000_DB9P193MB173996D59B99DB360545309FA3322DB9P193MB1739EURP_--