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 C3BEA43D05 for ; Wed, 20 Mar 2024 17:36:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3E6041132; Wed, 20 Mar 2024 17:36:56 +0100 (CET) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2082.outbound.protection.outlook.com [40.107.243.82]) by mails.dpdk.org (Postfix) with ESMTP id DE03840A6F for ; Wed, 20 Mar 2024 17:36:54 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dqlTRj1TzVSe55DYBU7f/Dzn1nmAjeXaa0YHO/aChxXMg6aX8Actf9Xvaka7+37Ul+271GDttOKmWwdAAx+6RHPMCql/mqLIggRFmwmgiFSA43NBbY10Gho24CMY4BCKEvJr2aEMvAngmeyWSVs/FLAiRRI0tDqcpGZS8KGGYrqY8Y+qExSuTmaDjzE01FaTX7aJ6uEaUZF3DujzZsYsLkWDGoG5BDEYEoswHvweAoZt6DNOS+oBNySoHUoT7uY8UxlCzh3mJb5YYI7XkmDMWz3JGYroA5Vt3Lqvqlo7KMZapKqfTuIXrz4RYaRNx/HPG2bUTWNVWS72piLAD4EIYg== 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=euKhd3WogBRHqeqp2KalzsnM+YcYgtJF8IS+xUjW8lE=; b=KNhJX/6jbuMgHx6PwZPOTUTukyhrI1xFwMIOnroDTQd8vcWAxPywZZxePBzmk1v59hLJiMYxMKr6EmdSaA7OPS7UFuY0VAZ23qQmVj4d/7zBeg1S581QJiyN+RQcHsgsz7EafnXGz7W845sx9uTqHmOl7n5fsrQakrxTWhuRkkiaOcjERUVtuX7SG1sfGBpt6gO+KJPVZlcRGWfJ4/2QaUS3TdY3qJsXcgkPSDScD8vtLskKbP95xhGiGAOaPf1XhXD0BD+6Nxj9SrndnBhF4tJJWKuQCWw3P9/Uy0G2J5wzzRh5nLSHarfV63ZXWGF6gqPyoUOl/xOtA1781NVcuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=euKhd3WogBRHqeqp2KalzsnM+YcYgtJF8IS+xUjW8lE=; b=SVFjL9veMciKUUuABdfnW6XCtCQVUsrTY4QCaz0sWd58N60eNRQSnp3piB6nl0nIbjoL+VeBisn+jIT10kFP7fGkGVtCG79fC/6iDNkGcbF+9/5USqA3MUM4t9g0xACs8VFrU6Kaa67c5wCWwA9To1qAO683CWddwpE4cQ7H1Ov2p5Vj9iuqG8gVfhcXcmyYJ0msk6O6TgQ2rUltJEBjno8GRGo4ojDlj9UJwO4Xskloykf9NomywDp2WafjLq1MaTTz6ngQPUC6KCZG0EF3NLccTwMVj1k0yazBjwR40LU3coqcwfUowcMFxGvGI/H6rIzzoxbt3BDQSsDaz2FzAw== Received: from IA1PR12MB6332.namprd12.prod.outlook.com (2603:10b6:208:3e2::13) by CH3PR12MB8076.namprd12.prod.outlook.com (2603:10b6:610:127::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.31; Wed, 20 Mar 2024 16:36:51 +0000 Received: from IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::abca:c0e2:1a95:d6ab]) by IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::abca:c0e2:1a95:d6ab%4]) with mapi id 15.20.7386.031; Wed, 20 Mar 2024 16:36:51 +0000 From: Gregory Etelson To: Tao Li , Suanming Mou , "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: AQHaeR69o94Z6fNcNEezdQ6xUTy3g7E+NUeAgADRCNyAAbthgIAAC62e Date: Wed, 20 Mar 2024 16:36:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: IA1PR12MB6332:EE_|CH3PR12MB8076:EE_ x-ms-office365-filtering-correlation-id: acf4d186-d5a9-47f7-5939-08dc48fbf1ce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AH5JQpXoUVIxf7S1sN8hcFbsqrQFOx07+xdttKz8JvyRt4uogx4LjfO9Ib3EM6o0XkR4+w9Ep+EtjWyJcpdJueh1Xm3RuFWRLf1wvnYqc3Ky9bCZTHiCfb7OL9dxO5OnqSODjQkNWgduO/kDXFj6IY++qglyiLhcQ6wULN9GU1I7oh9oPTiQXy0Tk3afhbcZgpKE1CqKImM7YDcdZOAOgHbk1OXS5jmnituaqw8ujVdME+UomKyk/XkA+mqSb6s+qMn/eRsKTnAkrOCMhQpPyTla9+6tYAO235msYDBwcKvqjxvUuF43exFK20u8PU3REWcKkgX241SN/eAba9lyzbGQ2mnfpTAwtDt0z9Rywqepo20OJo+nN+AhHrQ21SI2i89XUdi83dw2ZpXcRVdxc5ddsc9+TGjKayqOAPRXYrowfFAoFlkSbHRF2QzeNnd7TnJong7QyEGJ/sKHfms1A5Bfkx105aac8hXnQZYPk0MY+U9+zIt0YXxlgndNiKcgOpPmJcYR+Ve5HttzHoWumNyuQm+6WHDfAbOdFhikWTR+I0n1eZfr+kpsHHkxbO7XFdyjnGQehXhm5rjpbeLQqhOA9ShRYA1Ca9eRICytjnEpEBvtBCnbxdpDwwwr12lspF4T45gZTlz+uK+q0YCQokthtTqeSeuabJLxJYzJ3FP6ZskBYESLIkBjUGQxO9IAmu1BupZ1WR34ocBTL8z4oa/pAylWWL/j2Chc3lp4zBw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR12MB6332.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(366007)(376005)(38070700009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?LoM1GNjs7WuXOpxsrNdha/mVM5afA/IFCAobi9cXxmSGMrCYiSrzdWom?= =?Windows-1252?Q?Bl/vh7Ck3qxYq0dY+nd8WKKXkBUa8DSi40OkbsT09yb0s1ClSwzvn7Ni?= =?Windows-1252?Q?Kv1ETWXo+nd3bl26Jk/iIFAE2nGdJy8cEa5F64LgWto5gH8+YrU6fJd3?= =?Windows-1252?Q?Q7eyxl4o19KR+IOF+wXRXEiM/6ixIxn7+B/Nkl0dEFnKZocgF2bAGoE+?= =?Windows-1252?Q?ZZGz9sHKHfYu/hc1nbVwzTHzmQzp8BPKVs1JFrhK/lfrVVF6fCZM7lYM?= =?Windows-1252?Q?rYW7d+FE2H5O+XfoDFNlOjVlqfvUamB+MwsFOAKt7GFWGpSH7g6o4Aeg?= =?Windows-1252?Q?Ns6QwKYl8H521w4OEpRkdm2y8w8EwxFm60oS05TMCpBeRmnE3PaaP8Vl?= =?Windows-1252?Q?Z6RFeOiPFBPKYaMILtOw50PLPGD96CluZhfEg28jSgsZ+b+Pl2bZSkmO?= =?Windows-1252?Q?+sUHYnR2uT6DjnojVhaWdy2ZrgYRmiK0vQ8r811BaB3sJ4D5Abgd0EF5?= =?Windows-1252?Q?9qM/uiLUz1RB7LPlW1rqQ7RbmUOKfFhWt/X6NJT6/Cs14HWoPVz6vK8L?= =?Windows-1252?Q?9lvQbUfqOM2ZsOXK8HyM5UrM2qfS8YvU84lL6hjSmAxLR9ueBbU17b+2?= =?Windows-1252?Q?jtxtN2otiKz/HCaIxVjEkCKtudAXsqy0odoIIDpvHWjGEk+Xe3G5ZtIA?= =?Windows-1252?Q?Bpk80QijijCaQJk6s6dRvjDceA84EMo4TZL3Gq7F7eFtHFcqzxE2j4iZ?= =?Windows-1252?Q?4WOH96aFSMhutvMk2QcE8pcmJ5lf87LTjQxa8X99HuQ2styLs68X625y?= =?Windows-1252?Q?ZR4h3bAQst0lc7YXvoC6ZCF0BCFhsJhMPJF4Q5WC6p4JGZX1N7Q3d1ko?= =?Windows-1252?Q?qp5UlKvNroV1eDuN9sLyzqNtWVrFwdwJFFzqKoTWiDqu4W0fSboHX55s?= =?Windows-1252?Q?g7yiCnvzItbqylLy5W8BOpM8Mi6PM8MwgEyJA1i8LDt+a2CPJ15ClKXQ?= =?Windows-1252?Q?pxjO8dK7IDjFctjVumX70DX7dLFrZJfMilUG1rCACbhXuG8WfBJVbXCl?= =?Windows-1252?Q?bUxjNpkd7kJF92vQEMMTQjFsgLy/DUWAjWjrXndWNwG1P7uD3GAz7znV?= =?Windows-1252?Q?8oynsEr8zKNYe5qEW516cTeUGNaTROBzBKgPXJiyRf0hfxCOeeOfAE2g?= =?Windows-1252?Q?OVBXC4yOvPeRIvEkGvhq5pULM8gygzblyyBzE56B1lZF7Z+opm1+NwN1?= =?Windows-1252?Q?k8l5bLk+oIIoRCvsseUREkLw2WYpyVc8lMEAqRq07PwSAWDPOF/AySZX?= =?Windows-1252?Q?ezgoBFuZJ2WBdWk/OYXrz5j9To6kCAWnm6FqbocOfqBVZsWRZMj9heK9?= =?Windows-1252?Q?YNl1WaYx7WrE9/ZuYI+lPqTfCP1uqBP7ltBFKljtnIzWYAgogCd42eps?= =?Windows-1252?Q?soqkGgEfXo+PXTOPUS9j25MXAaHWzvp/tkp4lDMci6Lmnb2HRjov33va?= =?Windows-1252?Q?u00ATgD0TTWKJnT7YvlJ8eNh5+j/Dp+vt/LjFsQjqVUxz6RFKwDApXoS?= =?Windows-1252?Q?SHA8O3YS7z9zyhN/llWzWHjSDkMJYV32izU6OYzUsKDXnuF6JZiVfNFg?= =?Windows-1252?Q?K5hsKFQkDi1TDrV3VbXqSI5JK2RVQBrG8UDn4iavygjft96bxL7IGaf2?= =?Windows-1252?Q?9mC7x/ZxpW/ph9IDdnpK5wtsAJNbiArj?= Content-Type: multipart/alternative; boundary="_000_IA1PR12MB6332AA8B8B925ED03C28F259A5332IA1PR12MB6332namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6332.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: acf4d186-d5a9-47f7-5939-08dc48fbf1ce X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2024 16:36:50.9979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Enc5s3pNp73LsGg0Clk79sb9//mhOVKzLwbI/QX3HpsvqCg6hUVog6aojxyY4sgWJPgkwQfI5dmrPjAoAjwHfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8076 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_IA1PR12MB6332AA8B8B925ED03C28F259A5332IA1PR12MB6332namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_IA1PR12MB6332AA8B8B925ED03C28F259A5332IA1PR12MB6332namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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<= /span>

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_te= mplate 0 create transfer actions_template_id 1 template raw_decap / raw_encap index 0 / represented_port / end mask raw_d= ecap / raw_encap index 0 / represented_port / end

flow pattern_te= mplate 0 create transfer pattern_template_id 1 template eth / ipv6 / end

flow te= mplate_table 0 create transfer table_id 1 group 0 priority 0 rules_number 1= pattern_template 1 actions_template 1



Regards,
Gregory

From: Tao 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 links or attachments

= Hello Gregory,

=  

= I am the colleague from Guevenc. Thanks a lot= for providing detailed explaination, and we appreciate your support very m= uch.

= The guidance on the usage of the RAW_ENCAP ma= sk is adopted and experimented, which currently leads to the segmentation f= ault in our setup. The example code used to create the action template and table template is as following:

=  

= <C= ode Excerpt>

=  &n= bsp;            = ;  // first action template

=  &n= bsp;            = ;  struct rte_flow_action_raw_decap decap_action =3D {.size =3D (sizeo= f(struct rte_ether_hdr)+sizeof(struct rte_ipv6_hdr))}; // remove IPinIP packet=92s header

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

=  

=  &n= bsp;            = ;  struct rte_flow_action act[] =3D {

=  &n= bsp;            = ;            &n= bsp;     [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_DE= CAP, .conf =3D &decap_action}, //?

=  &n= bsp;            = ;            &n= bsp;     [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_EN= CAP, .conf =3D &encap_action}, //?

=  &n= bsp;            = ;            &n= bsp;     [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REPRES= ENTED_PORT,},

=  &n= bsp;            = ;            &n= bsp;     [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END,},=

=  &n= bsp;            = ;  };

=  

=  &n= bsp;            = ;  struct rte_flow_action msk[] =3D {

=  &n= bsp;            = ;            &n= bsp;     [0] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_DE= CAP, .conf=3D &decap_action},

=  &n= bsp;            = ;            &n= bsp;     [1] =3D {.type =3D RTE_FLOW_ACTION_TYPE_RAW_EN= CAP, .conf=3D &encap_action},

=  &n= bsp;            = ;            &n= bsp;     [2] =3D {.type =3D RTE_FLOW_ACTION_TYPE_REPRES= ENTED_PORT,},

=  &n= bsp;            = ;            &n= bsp;     [3] =3D {.type =3D RTE_FLOW_ACTION_TYPE_END,},=

=  &n= bsp;            = ;  };

=  

=  &n= bsp;            = ;  port_template_info_pf.actions_templates[0] =3D create_actions_templ= ate(main_eswitch_port, act, msk);

=  

=  &n= bsp;            = ;  // create template table

=  &n= bsp;            = ;  port_template_info_pf.template_table =3D create_table_template(main= _eswitch_port, &table_attr_pf,

=  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   (struct rte_flow_pattern_template **)&port_template_in= fo_pf.pattern_templates, MAX_NR_OF_PATTERN_TEMPLATE,

=  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   (struct rte_flow_actions_template **)&port_template_in= fo_pf.actions_templates, MAX_NR_OF_ACTION_TEMPLATE);

=  

= </= Code Excerpt>

=  

= Using gdb, the following = segfault trace is captured:

=  = ;

= <T= race Excerpt>

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

= #1 = 0x00005555579c2136 in mlx5dr_action_handle_tunnel_l3_to_l2 (action=3D0x555= 55f089dc0, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, log_bulk_sz=3D1) at ../drivers/net/mlx5/hws/mlx5dr_action.c:1468

= #2 = 0x00005555579bd56f in mlx5dr_action_create_reformat_hws (action=3D0x55555f= 089dc0, 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=3D0x55555e756b40,= reformat_type=3DMLX5DR_ACTION_TYP_REFORMAT_TNL_L3_TO_L2, num_of_hdrs=3D1 '\001', hdrs=3D0x7fffffffb720, log_bulk_size=3D1, flags=3D= 32) at ../drivers/net/mlx5/hws/mlx5dr_action.c:1594

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

= #5 = 0x000055555795f133 in mlx5_hw_build_template_table (dev=3D0x555559167300 &= lt;rte_eth_devices>, nb_action_templates=3D1 '\001', action_templates=3D0x555558dc1830 <port_template_info_pf+16>, at=3D0= x7fffffffcf00, tbl=3D0x17fdd1280, error=3D0x7fffffffd050)

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

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

=  &n= bsp;  action_templates=3D0x555558dc1830 <port_template_info_pf+16&g= t;, 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=3D0x555559167300 = <rte_eth_devices>, attr=3D0x5555589cc1e4 <table_attr_pf>, item_templates=3D0x555558dc1828 <port_template_info_pf+8>, nb_item_t= emplates=3D1 '\001',

=  &n= bsp;  action_templates=3D0x555558dc1830 <port_template_info_pf+16&g= t;, 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 <rte= _eth_devices>, attr=3D0x5555589cc1e4 <table_attr_pf>, item_templates=3D0x555558dc1828 <port_template_info_pf+8>, nb_item_t= emplates=3D1 '\001',

=  &n= bsp;  action_templates=3D0x555558dc1830 <port_template_info_pf+16&g= t;, 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, table_a= ttr=3D0x5555589cc1e4 <table_attr_pf>, pattern_templates=3D0x555558dc1= 828 <port_template_info_pf+8>, nb_pattern_templates=3D1 '\001',

=  &n= bsp;  actions_templates=3D0x555558dc1830 <port_template_info_pf+16&= gt;, nb_actions_templates=3D1 '\001', error=3D0x7fffffffe0f8) at ../lib/ethdev/rte_flow.c:1928

= </= Trace Excerpt>

=  

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

=  

= Best regards,

= Tao Li

=  

= From: Gregory Etelson <getelson@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 act= ions template are translated according to these general rules:

  1. If flow action configuration in template mask was not NULL, PMD constru= cts 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.    <= /li>
  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 (&= quot;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.

= 2e5= 43b6f18a2 does n= ot allow access to RAW_ENCAP configuration if the action did not provide correct mask.

=  

= If flow action configuration= has several parameters, the action template can be partially translated -<= br> 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 u= sed for pre-defined flow actions. 

=  

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

= Therefore, the RAW_ENCAP tem= plate configuration can be fully masked with the action size and data or pa= rtially masked with size only.

=  

= Regards,

= Gregory

=  

=  

= From: Suanming 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 &l= t;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 estab= lished as the new standard rte_flow API.

 

I have the following raw_encap pr= oblem when using the rte_flow async/template API 

with mlx5 driver:

- raw_encap rte_flow action templ= ate fails during validation when the action mask

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

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

to be NULL.

<Excerpt from commit 7f6daa490= d9>

    2. RAW encap (encap= _data: raw)     

         = ;   action conf (raw_data)            &n= bsp;                  <= /p>

         = ;                     &nb= sp;                     &= nbsp;            

         = ;   a. action mask conf (not NULL)          &= nbsp;      

         = ;     - encap_data constant.          &n= bsp;                  <= /p>

         = ;   b. action mask conf (NULL)           = ;                     &nb= sp;                     &= nbsp;                    =                 

         = ;     - encap_data will change.

</Excerpt from commit 7f6daa49= 0d9>

 

Commenting out the raw_encap vali= dation would make it possible to create

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

Things seem to work after relaxin= g the rte_flow raw_encap validation.

The change would look like:

 

[Suanming] I guess maybe it is du= e to the raw_encap and raw_decap combination. I added Gregory who added tha= t code maybe can explain it better. @Gregory Etelson

 

<Excerpt>

diff --git a/drivers/net/mlx5/mlx= 5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c

index 35f1ed7a03..3f57fd9286 1006= 44

--- a/drivers/net/mlx5/mlx5_flow_= hw.c

+++ b/drivers/net/mlx5/mlx5_flow_= hw.c

@@ -6020,10 +6020,10 @@ flow_hw_v= alidate_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->conf;<= /p>

 

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

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

         = ;       return rte_flow_error_set(error, EINVAL,

         = ;                     &nb= sp;           RTE_FLOW_ERROR_TYPE_ACTION, mask,

-        &nbs= p;                     &n= bsp;          "raw_encap: size must be masked= ");

+        &nbs= p;                     &n= bsp;          "raw_encap: size must be masked= "); */

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

         = ;       return rte_flow_error_set(error, EINVAL,

         = ;                     &nb= sp;           RTE_FLOW_ERROR_TYPE_ACTION, action,<= /span>

</Excerpt>

 

But this can not be the proper so= lution. Please advise a solution how to make the 

raw_encap work with rte_flow temp= late/async API. If relaxing the validation is ok, I can 

also prepare and send a patch.

 

Thanks in advance,

 

Guvenc Gulce

  

--_000_IA1PR12MB6332AA8B8B925ED03C28F259A5332IA1PR12MB6332namp_--