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 97A294342E for ; Fri, 22 Mar 2024 14:19:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E6D9402A7; Fri, 22 Mar 2024 14:19:08 +0100 (CET) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2077.outbound.protection.outlook.com [40.92.90.77]) by mails.dpdk.org (Postfix) with ESMTP id 78E7640284 for ; Fri, 22 Mar 2024 14:19:06 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oYegkzKujzAG/PDhNmdNF6+BfTwW5+k3h/fIsomxlNWgoHpwVQo7G0VusZdOs21XQa1mCU5GxE6qWQmC2ny2vGpAA3IFEsqOzhwLp6/CbSEyQTiQ3hLlknxJ/hvBOhFbw3gg6G0nNsq/oIgbdodZ9/sUbhyfAHHN5JQPaY6YV6fiPjmfQwfmPX4IsZzeWzCUZIEP2+Dv8WgPPFp+hASwjpcfs/s+FkJ4DUcnLp32QKSOkg5KGW+ZKHrV41ZJ3WHr4LfTtLFvetqvVxNBER905YmLz2BNGvCfnlvGyT2Mv4vE0ddLfVRGkcnUje7qSywMTZX+/WAHCmag/geAq1zJmw== 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=+H5MqldVy+yEUFrgPJSc4Hjjc9uQar5bUsNOQcsed5U=; b=E2RtLSdtaHM7yYlwG6Cm/hdXHvOt6uvDdDJWNR7rTHriOTpm+7Cu1xbV1aTvHkY5tuTGPUAeVKut0DIirb32ty3QELJ0oX8IJOLAt/g9QZSkK5Ueq//vMcQZPhALmd1rwFh2zUZ7UFR+ABiJE75WWxAxzy+P8FFTtpvX5oJlhK/SjV6VjrmqISfXxU94m9J92R4yRrIfHnBmipFkHxOmR6TytqBsnqWalFaVDYpF+Gn0oVntXafZ7NMiPSX7o6WOStzLOVvCnyv6fjIR27phoGVj8mxM85CwDVGAZ1B8RCw9e3vXmT/oCopoX1G0tFUHFnD/ACDokZXNWfbHtZd6Ug== 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=+H5MqldVy+yEUFrgPJSc4Hjjc9uQar5bUsNOQcsed5U=; b=sPMl7qBmU4/UNWZiYvEQOkXHkpW2id7pbdhazpP5CfZBRYJy+nYuTCovkw6qIvwLFoWDdgmknjTCTaL0wk8yhjIS4cPmKPBliT6DspbAGR+iWvT/G0lhAR59ea2C9OR+Ib/7KM59ZfS89T53wMNXYcZ0CPftiRKu7WUq1ApctQ/BXKmTbP0rQNLIaQoT+r+iBzblJ/AhEg21Xotlku92z3iNr39A2jvi3Wr25s2x/PCwvzstofotuAAsKxr99Trj50qIv/iIkcfPsuqS9T10Y7xPXXBmuAQsNkoWSkCKK/IxtBYq97BjseYLLGSaeMrS/BPC22F/X9y3x0eOvjd5+Q== Received: from DB9P193MB1739.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:24f::20) by AS8P193MB1271.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:333::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Fri, 22 Mar 2024 13:19:04 +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.7409.023; Fri, 22 Mar 2024 13:19:04 +0000 From: Tao Li To: Asaf Penso , "users@dpdk.org" Subject: Re: Finer matching granularity with async template API Thread-Topic: Finer matching granularity with async template API Thread-Index: AQHae6BPNEwcGktAFESopA2jvtTxHrFCkUNugAAAdQaAAQY17g== Date: Fri, 22 Mar 2024 13:19:04 +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: [2fzqu64+jSbVUi9D808LSIivf/giJ9gC] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9P193MB1739:EE_|AS8P193MB1271:EE_ x-ms-office365-filtering-correlation-id: 445887dc-b8a3-4dc9-abf1-08dc4a72a5b5 x-ms-exchange-slblob-mailprops: BG3AXrlrvvrsPTJDEpWWGy24uyAizBFH3ZbnLwyBUR1MO047X+lOcf0v43itcXu/prSIr6/Teut1YUBrUATSgZtQNeug3eHwxZoj3CetdCksEXmRoWHb+y8p2nCTkEZQaZP1QuYL0MM/jc7KRc47MW7YVNaBdIxyihjce/ZXg+o6xFLu3Sr68sKRBzM/mdg3V4qwTZVZVsB35KE31OTmCjhxQu9uVkoq+S82F8glQD5J+JHaH+x76zCPOhZyDFHtjof5HcSPoiLEw4/AUNsKyEk0kH9UHNvECflWPKDWs6y9ZTintgWGUKg9NQsbeDrj8wCrA8hSsaj2FSXuhYssVzXDCHIoxoEhV7z6mfMf0Ua5l8U/rPnIaKVNUe76RjehdeDqiTShq57Sz1xbapG86c3MIwjxi7IMY4JbVBZwv4uDp2S1zmRog87Bf1ygMlx3PHVc2hQiQoLrD646vva5NM/Ry1RL62Kjxp3/H8eYoaHQFaFR18IMv6e+7cmsdF8av20ybVlBOpMu5Qv7Dxn+G8Ek1pXAeMltY85tb7rpJUiK5Evec+poq19An1ApKwmMXupPqxJFw2Z38Z2d2HvBh53wV2LPAG0S3zNGAzj0+HaogzsL6X5aOAVtLHcGkScBv/Nrbw2Yp+5884gsQ8vWKxLtehtTclXK7lj5ovqZGQ/AXEv4i7LcfUYufjQXGzuDHNvVqG6Zv3zF/93Sb0Pcp9roorGwd1ssqd5aXdzNfR2nGDcNjzPakvbaMP/CD4CNRF96Bp2Mq9D1oxP2JHJAT96qCxhAiXISmlabJLDAMRVUVy9YVaoocA== x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zW97RyL/yuUAMi5MW0X4w5KD+e8mQjWUohDb1ZjS0u4ktGL/i0npxOW8hZI9DyTRI1qERHtHynGXM4SYukz0WUBSvyiWMhtZEMsAvbbGq3iEDbvs5VGQ1e2U2TB0wpJIxWyjc8M3oxLCQjnWuAsHaMb1lNdDZYu9EFhJZzvgoh6AGOPxsIMJWFX1f/KkLePKorI7exy1xupVe/BRCrG+XT8I3genwz1N+hqcPyqMRU2uhUWDOGI9/eSvpAmwmIZXbgHdOS4zrKeJ20VCR34YRHwuINhMKipv9mKji3ajG58tbRtqQ+ijmxQV4JQXnx5V0eklJU4Dz4Wcy7/eSYVdva5sBAYBAfYSV9U0aP23XJgHSiND8Fv9KncJ9+tgiEDjA7U3Th7tVBLQ0Q2dLLe1Hx+ZbdsL7y17orxT+Kti2pvebdJ+jF1tFNYwfylIjgSO9uaoaZJ/7rgtneFUvvaAVisNVmTC4CvGT4jRCG/FOjN7kbEqbihCfxwrUlt7GTcXfXhxCgkAE7yG2gxB5yxqEIC7Cx5LGCu0v2465osmRJLrpWKmW9baP3vpDuKcddt+6uZZA/cPwHtDamEvk41FJ9fFzP3v/HvLiMeanUkQwZe5ybiqeIo3Wx4L3lO7c4ThMiTT7EZaCuIvjn1GRdaFBout6SkRjkvLBEgA+PfmVZLn0p+YVMKFeq6Cl+Mvm/qJ x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?vg3vhi1lL141LCMtc7QWwEqE5vpbeLD/g3Jvhe1w0wxcHp/sGWEPBmNu?= =?Windows-1252?Q?exgNKBaMNlJ3F98fJbIB8SZqtH3X7EeCJWzY6TVmJpC49hLHgG5gt2GF?= =?Windows-1252?Q?gjPJPfQM4lXhEbrDKgZ7MaWIBRdI1Uw2f6oRy9/njAhoa9YkN/SW2eQP?= =?Windows-1252?Q?EgB+zGp5bnmL/66KqggtXUaCL15jKsVkeliTJoB1OyHuGFNou7BcyyVD?= =?Windows-1252?Q?KIppvh4nthFNL0K87VFbIAK970BHM5Amywr0KhRf6+yIGTMFfTK7cn54?= =?Windows-1252?Q?px6liz0VffZzFrDZA+pXTjJiyAUPiCNbR7/JLeNsk04zbqCs3uzRApxT?= =?Windows-1252?Q?S+zqFkuul+0hgb/yoY1Lj9FGZOB21so0+fHHrzvy5dOdgYdwgMCmfRHv?= =?Windows-1252?Q?rzxR9zSPHAy0wytKzP7fEmJc8Y7Uk0SEJJZg6YZAGcUd1CKXBLSa3l4K?= =?Windows-1252?Q?QJJhxy5+oHsPDitLy39WB0OGxFoKG4jOr8Kp+a9jAa7PgXAcQyiHkP21?= =?Windows-1252?Q?bhXcYkheZuYEAYnAxdTYALnz8Oja6h+2VuJhkz1Gmoi9aavt0JbmXhYu?= =?Windows-1252?Q?wHHtGRys9VNFaSb0aLBfxsIy8ZiXPS8Iv42/28CZnMl9gJaLu3MK0yhg?= =?Windows-1252?Q?SxUClGPwyc32PL34fi5hHi0sLv+iseatpmZvugwNY5wPvcJmIw55yLjA?= =?Windows-1252?Q?WaTW4hGnACgPNZ1DNzkRzj1HCoP8o0iDJazgR2x81gPeTKTxv2m6vN6t?= =?Windows-1252?Q?dd9W8eU8TblgQJNCQaPC1a2Ilth1Xf2JjmY+7OT3UIAfng+DU96h015r?= =?Windows-1252?Q?2OZv+UH4JX+7q2sDslkd8TsINEKjwxXwWrTblLaTXB1RsvVPcX87r3Qq?= =?Windows-1252?Q?08JLgw5nvtdwyg1Bw/fbS3h0n4i1R5K++Jz6H1qABkmrDDd7qnbv8rS7?= =?Windows-1252?Q?ANh93lzp0NuRYuw/wYg15wP/bn8dKso7E62Zu3nAPEsp0k1aHLgCTEjy?= =?Windows-1252?Q?knDT0XaCJl5W1hU5bDDlb5a5VpYX178I/Z60JUR9v3dXXug2wjo+U7KB?= =?Windows-1252?Q?3AmHsANdNG3dDp0hpFAuArysBspxvrRDoJq/DGaYhdsQY6oZAgLR7hG/?= =?Windows-1252?Q?U5QWMIgagmF/1g7O/hi4Dsd320n9Vsfp5Bb8Ef+ofKSTlzx0J2BfMS2C?= =?Windows-1252?Q?rjiMtPmx+N0QcmpN1FaRw5hsnKsiMerzqfBTlL1FHXoAtkR/zS999ze7?= =?Windows-1252?Q?H61aXKk2glqxbR0Wg9VUEQdBVMyGM0jX0y1h+SiaQoj7FYgUyZRIKjBP?= =?Windows-1252?Q?JylvVv84iSe8AOoMZlMe2zZKPnV/FLHU1uxgPDlSmxoWg1Vi?= Content-Type: multipart/alternative; boundary="_000_DB9P193MB17394A00CCEB00D137FA6264A3312DB9P193MB1739EURP_" 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: 445887dc-b8a3-4dc9-abf1-08dc4a72a5b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 13:19:04.6390 (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: AS8P193MB1271 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_DB9P193MB17394A00CCEB00D137FA6264A3312DB9P193MB1739EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hellp Asaf, Thanks for your speedy reply. Please find additional information based on y= our questions, and I hope they would help to understand our purpose and iss= ue. 1. Why ipv6/ipv4/icmp? We are performing IPinIP tunnelling for traffic, and in this provided test-= pmd example we encapsulate IPv4 packets from VMs into IPv6 underlay packets= . The refence RFCs for this approach are RFC 1853 and RFC 2473. This articl= e also provides goo= d visualization on packet structures for this IPinIP tunnelling approach. 1. What output /error message? No crashing error message or similar happens, thus it is difficult for us t= o debug what is exactly going on. What is observed is that incoming packets= cannot be captured and processed by this flow rule, compared with using t= he flow rule only performs eth/ipv6 matching. After removing relevant comma= nds or code that perform inner header matching for IPv4 and ICMP, packets c= an be successfully processed. The code snippets to programmably achieve the= above described IPinIP tunnelling approach are as following: static const struct rte_flow_item_eth flow_item_eth_mask =3D { .hdr.ether_type =3D 0xffff, }; static const struct rte_flow_item_ipv6 flow_item_ipv6_dst_mask =3D { .hdr.proto =3D 0xff, }; static const struct rte_flow_item_ipv4 flow_item_ipv4_proto_mask =3D { .hdr.next_proto_id =3D 0xff, }; static const struct rte_flow_item_icmp flow_item_icmp_mask =3D { .hdr.icmp_type =3D 0xff, }; // pattern template struct rte_flow_item pattern[] =3D { [0] =3D {.type =3D RTE_FLOW_ITEM_TYPE_REPRE= SENTED_PORT, .mask =3D &represented_port_mask}, [1] =3D {.type =3D RTE_FLOW_ITEM_TYPE_ETH, = .mask =3D &flow_item_eth_mask}, [2] =3D {.type =3D RTE_FLOW_ITEM_TYPE_IPV6,= .mask =3D &flow_item_ipv6_dst_mask}, [3] =3D {.type =3D RTE_FLOW_ITEM_TYPE_IPV4,= .mask =3D &flow_item_ipv4_proto_mask}, [4] =3D {.type =3D RTE_FLOW_ITEM_TYPE_ICMP,= .mask =3D &flow_item_icmp_mask}, [5] =3D {.type =3D RTE_FLOW_ITEM_TYPE_END,}= , }; port_template_info_pf.pattern_templates[0] =3D create_patte= rn_template(main_eswitch_port, pattern); struct rte_flow_item_eth eth_pattern =3D {.type =3D htons(0= x86DD)}; struct rte_flow_item_ipv6 ipv6_hdr =3D {0}; ipv6_hdr.hdr.proto =3D IPPROTO_IPIP; struct rte_flow_item_ipv4 ipv4_hdr =3D {0}; ipv4_hdr.hdr.next_proto_id =3D IPPROTO_ICMP; struct rte_flow_item_icmp icmp_hdr =3D {0}; icmp_hdr.hdr.icmp_type =3D RTE_IP_ICMP_ECHO_REQUEST; struct rte_flow_item_ethdev represented_port =3D {.port_id = =3D pf_port_id}; struct rte_flow_item concrete_patterns[6]; concrete_patterns[0].type =3D RTE_FLOW_ITEM_TYPE_REPRESENTE= D_PORT; concrete_patterns[0].spec =3D &represented_port; concrete_patterns[0].mask =3D NULL; concrete_patterns[0].last =3D NULL; concrete_patterns[1].type =3D RTE_FLOW_ITEM_TYPE_ETH; concrete_patterns[1].spec =3D ð_pattern; concrete_patterns[1].mask =3D NULL; concrete_patterns[1].last =3D NULL; concrete_patterns[2].type =3D RTE_FLOW_ITEM_TYPE_IPV6; concrete_patterns[2].spec =3D &ipv6_hdr; concrete_patterns[2].mask =3D NULL; concrete_patterns[2].last =3D NULL; concrete_patterns[3].type =3D RTE_FLOW_ITEM_TYPE_IPV4; concrete_patterns[3].spec =3D &ipv4_hdr; concrete_patterns[3].mask =3D NULL; concrete_patterns[3].last =3D NULL; concrete_patterns[4].type =3D RTE_FLOW_ITEM_TYPE_ICMP; concrete_patterns[4].spec =3D &icmp_hdr; concrete_patterns[4].mask =3D NULL; concrete_patterns[4].last =3D NULL; concrete_patterns[5].type =3D RTE_FLOW_ITEM_TYPE_END; concrete_patterns[5].spec =3D NULL; concrete_patterns[5].mask =3D NULL; concrete_patterns[5].last =3D NULL; Looking forward to your further support, and many thanks in advance. Best regards, Tao From: Asaf Penso Date: Thursday, 21. March 2024 at 20:18 To: Tao Li , users@dpdk.org Subject: Re: Finer matching granularity with async template API BTW, In the non working example I see ipv6 / ipv4 / ICMP. Was this your intentio= n or did you mean ipv6 / ICMP? Regards, Asaf Penso ________________________________ From: Asaf Penso Sent: Thursday, March 21, 2024 9:17:04 PM To: Tao Li ; users@dpdk.org Subject: Re: Finer matching granularity with async template API Hello Tao, What is the output / error message you get? Regards, Asaf Penso ________________________________ From: Tao Li Sent: Thursday, March 21, 2024 5:44:00 PM To: users@dpdk.org Subject: Finer matching granularity with async template API Hi all, I am using async template API to install flow rules to perform actions on p= ackets to achieve IP(v4)inIP(v6) tunnelling. Currently I am facing an issue= where I cannot perform incoming traffic matching with finer granularity. T= he test-pmd commands in use are as following: port stop all flow configure 0 queues_number 4 queues_size 64 counters_number 0 aging_cou= nters_number 0 meters_number 0 flags 0 # PF0 flow configure 1 queues_number 4 queues_size 64 counters_number 0 aging_cou= nters_number 0 meters_number 0 flags 0 flow configure 2 queues_number 4 queues_size 64 counters_number 0 aging_cou= nters_number 0 meters_number 0 flags 0 flow configure 3 queues_number 4 queues_size 64 counters_number 0 aging_cou= nters_number 0 meters_number 0 flags 0 # PF1V0 port start all set verbose 1 flow pattern_template 0 create transfer relaxed no pattern_template_id 10 = template represented_port ethdev_port_id is 0 / eth / ipv6 / ipv4 / icmp = / end set raw_decap 0 eth / ipv6 / end_set set raw_encap 0 eth src is 11:22:33:44:55:66 dst is 66:9d:a7:fd:fb:43 type = is 0x0800 / end_set flow actions_template 0 create transfer actions_template_id 10 template r= aw_decap index 0 / raw_encap index 0 / represented_port / end mask raw_deca= p index 0 / raw_encap index 0 / represented_port / end flow template_table 0 create group 0 priority 0 transfer wire_orig table_= id 5 rules_number 8 pattern_template 10 actions_template 10 flow queue 0 create 0 template_table 5 pattern_template 0 actions_template = 0 postpone no pattern represented_port ethdev_port_id is 0 / eth / ipv6 /= ipv4 / icmp / end actions raw_decap index 0 / raw_encap index 0 / repres= ented_port ethdev_port_id 3 / end flow push 0 queue 0 Once I remove matching patterns for the inner packet headers( ipv4 / icmp) = as following, I can see the processed packets inside VMs using tcpdump. =85 flow pattern_template 0 create transfer relaxed no pattern_template_id 10 = template represented_port ethdev_port_id is 0 / eth / ipv6 / end =85 flow queue 0 create 0 template_table 5 pattern_template 0 actions_template = 0 postpone no pattern represented_port ethdev_port_id is 0 / eth / ipv6 = / end actions raw_decap index 0 / raw_encap index 0 / represented_port eth= dev_port_id 3 / end =85 Similar combination works when using the synchronous rte_flow API. Any comm= ent or suggestion on this issue is much appreciated. Many thanks in advance= . Best regards, Tao --_000_DB9P193MB17394A00CCEB00D137FA6264A3312DB9P193MB1739EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hellp Asaf,

 

Thanks for your spe= edy reply. Please find additional information based on your questions, and = I hope they would help to understand our purpose and issue.

 

  1. Why ipv6/ipv4/icmp?

We are perfo= rming IPinIP tunnelling for traffic, and in this provided test-pmd example = we encapsulate IPv4 packets from VMs into IPv6 underlay packets. The refenc= e RFCs for this approach are RFC 1853 and RFC 2473. This article also provides good visualization on packet structures for this = IPinIP tunnelling approach.

 <= /o:p>

  1. What output /error message?

No crashing = error message or similar happens, thus it is difficult for us to debug what= is exactly going on. What is observed is that incoming packets cannot be captured and processed by this flow rule,  compared w= ith using the flow rule only performs eth/ipv6 matching. After removing rel= evant commands or code that perform inner header matching for IPv4 and ICMP, packet= s can be successfully processed. The code snippets to programmably achieve = the above described IPinIP tunnelling approach are as following:=

 <= /o:p>

<Code = snippet to initialise pattern masks>

static const struct rte_flow_item_eth flow_item_eth_mask =3D {

           = ;     .hdr.ether_type =3D 0xffff,

};

 

static const struct rte_flow_item_ipv6 flow_item_ipv6_dst_mask = =3D {

           = ;     .hdr.proto =3D 0xff,

};

 

static const struct rte_flow_item_ipv4 flow_item_ipv4_proto_mask = =3D {

           = ;     .hdr.next_proto_id =3D 0xff,

};

 

static const struct rte_flow_item_icmp flow_item_icmp_mask =3D {<= o:p>

           = ;     .hdr.icmp_type =3D 0xff,

};

</Code= snippet to initialise pattern masks>

 <= /o:p>

<Code = snippet to create pattern template>

  =             &nb= sp; // pattern template

  =             &nb= sp; struct rte_flow_item pattern[] =3D {

  =             &nb= sp;            =      [0] =3D {.type =3D RTE_FLOW_ITEM_TYPE_REPRESENTED_= PORT, .mask =3D &represented_port_mask},

  =             &nb= sp;            =      [1] =3D {.type =3D RTE_FLOW_ITEM_TYPE_ETH, .mask = =3D &flow_item_eth_mask},

  =             &nb= sp;            =      [2] =3D {.type =3D RTE_FLOW_ITEM_TYPE_IPV6, .mask = =3D &flow_item_ipv6_dst_mask},

  =             &nb= sp;            =      [3] =3D {.type =3D RTE_FLOW_ITEM_TYPE_IPV4, .mask = =3D &flow_item_ipv4_proto_mask},

  =             &nb= sp;            =      [4] =3D {.type =3D RTE_FLOW_ITEM_TYPE_ICMP, .mask = =3D &flow_item_icmp_mask},

  =             &nb= sp;            =      [5] =3D {.type =3D RTE_FLOW_ITEM_TYPE_END,},<= /o:p>

  =             &nb= sp; };

  =             &nb= sp; port_template_info_pf.pattern_templates[0] =3D create_pattern_template(= main_eswitch_port, pattern);

</Code= snippet to create pattern template>

 <= /o:p>

<Code = snippet to create patterns>

  =             &nb= sp; struct rte_flow_item_eth eth_pattern =3D {.type =3D htons(0x86DD)};

 

  =             &nb= sp; struct rte_flow_item_ipv6 ipv6_hdr =3D {0};

  =             &nb= sp; ipv6_hdr.hdr.proto =3D IPPROTO_IPIP;

 <= /o:p>

  =             &nb= sp; struct rte_flow_item_ipv4 ipv4_hdr =3D {0};

  =             &nb= sp; ipv4_hdr.hdr.next_proto_id =3D IPPROTO_ICMP;

 <= /o:p>

  =             &nb= sp; struct rte_flow_item_icmp icmp_hdr =3D {0};

  =             &nb= sp; icmp_hdr.hdr.icmp_type =3D RTE_IP_ICMP_ECHO_REQUEST;<= /p>

 <= /o:p>

  =             &nb= sp; struct rte_flow_item_ethdev represented_port =3D {.port_id =3D pf_port_= id};

 <= /o:p>

  =             &nb= sp; struct rte_flow_item concrete_patterns[6];

 <= /o:p>

  =             &nb= sp; concrete_patterns[0].type =3D RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT;=

  =             &nb= sp; concrete_patterns[0].spec =3D &represented_port;<= /p>

  =             &nb= sp; concrete_patterns[0].mask =3D NULL;

  =             &nb= sp; concrete_patterns[0].last =3D NULL;

 <= /o:p>

 <= /o:p>

  =             &nb= sp; concrete_patterns[1].type =3D RTE_FLOW_ITEM_TYPE_ETH;=

  =             &nb= sp; concrete_patterns[1].spec =3D &eth_pattern;

  =             &nb= sp; concrete_patterns[1].mask =3D NULL;

  =             &nb= sp; concrete_patterns[1].last =3D NULL;

 <= /o:p>

  =             &nb= sp; concrete_patterns[2].type =3D RTE_FLOW_ITEM_TYPE_IPV6;

  =             &nb= sp; concrete_patterns[2].spec =3D &ipv6_hdr;

  =             &nb= sp; concrete_patterns[2].mask =3D NULL;

  =             &nb= sp; concrete_patterns[2].last =3D NULL;

 <= /o:p>

  =             &nb= sp; concrete_patterns[3].type =3D RTE_FLOW_ITEM_TYPE_IPV4;

  =             &nb= sp; concrete_patterns[3].spec =3D &ipv4_hdr;

  =             &nb= sp; concrete_patterns[3].mask =3D NULL;

  =             &nb= sp; concrete_patterns[3].last =3D NULL;

 <= /o:p>

  =             &nb= sp; concrete_patterns[4].type =3D RTE_FLOW_ITEM_TYPE_ICMP;

  =             &nb= sp; concrete_patterns[4].spec =3D &icmp_hdr;

  =             &nb= sp; concrete_patterns[4].mask =3D NULL;

  =             &nb= sp; concrete_patterns[4].last =3D NULL;

 <= /o:p>

  =             &nb= sp; concrete_patterns[5].type =3D RTE_FLOW_ITEM_TYPE_END;=

  =             &nb= sp; concrete_patterns[5].spec =3D NULL;

  =             &nb= sp; concrete_patterns[5].mask =3D NULL;

  =             &nb= sp; concrete_patterns[5].last =3D NULL;

</Code= snippet to create patterns>

 <= /o:p>

 <= /o:p>

Looking forward to = your further support, and many thanks in advance.

 

Best regards,<= /o:p>

Tao

 <= /o:p>

 

From: Asaf Penso <asafp@nvidia.com><= br> Date: Thursday, 21. March 2024 at 20:18
To: Tao Li <byteocean@hotmail.com>, users@dpdk.org <users@d= pdk.org>
Subject: Re: Finer matching granularity with async template API=

BTW,

In the non working example I see ipv6 / ipv4 / ICMP.= Was this your intention or did you mean ipv6 / ICMP?

 

Regards,

Asaf Penso

From: Asaf P= enso <asafp@nvidia.com>
Sent: Thursday, March 21, 2024 9:17:04 PM
To: Tao Li <byteocean@hotmail.com>; users@dpdk.org <users@d= pdk.org>
Subject: Re: Finer matching granularity with async template API

 

Hello Tao,

 

What is the output / error message you get?

 

 

Regards,

Asaf Penso

From: Tao Li= <byteocean@hotmail.com>
Sent: Thursday, March 21, 2024 5:44:00 PM
To: users@dpdk.org <users@dpdk.org>
Subject: Finer matching granularity with async template API <= /p>

 

Hi= all,

&n= bsp;

I = am using async template API to install flow rules to perform actions on pac= kets to achieve IP(v4)inIP(v6) tunnelling. Currently I am facing an issue w= here I cannot perform incoming traffic matching with finer granularity. The test-pmd commands in use are as follo= wing:

&n= bsp;

<Not working test-pmd commands>

port stop all

 

flow configure 0 = queues_number 4 queues_size 64 counters_number 0 aging_counters_number 0 me= ters_number 0 flags 0   # PF0

 

flow configure 1 = queues_number 4 queues_size 64 counters_number 0 aging_counters_number 0 me= ters_number 0 flags 0

 

flow configure 2 = queues_number 4 queues_size 64 counters_number 0 aging_counters_number 0 me= ters_number 0 flags 0

 

flow configure 3 = queues_number 4 queues_size 64 counters_number 0 aging_counters_number 0 me= ters_number 0 flags 0  # PF1V0

 

port start all

set verbose 1

 

flow pattern_temp= late 0 create transfer relaxed no pattern_template_id 10  template rep= resented_port ethdev_port_id is 0 / eth  / ipv6 / ipv4 / icmp  / end

 

set raw_decap 0 e= th  / ipv6 / end_set

set raw_encap 0 e= th src is 11:22:33:44:55:66 dst is 66:9d:a7:fd:fb:43 type is 0x0800 / end_s= et

 

flow actions_temp= late 0 create transfer  actions_template_id 10  template raw_deca= p index 0 / raw_encap index 0 / represented_port / end mask raw_decap index= 0 / raw_encap index 0 /  represented_port  / end

 

flow template_tab= le 0 create  group 0 priority 0  transfer wire_orig table_id 5 ru= les_number 8 pattern_template 10 actions_template 10

 

flow queue 0 crea= te 0 template_table 5 pattern_template 0 actions_template 0 postpone no pat= tern represented_port ethdev_port_id is 0 / eth  / ipv6  / ipv4 / icmp  / end actions raw_decap index 0 / raw_encap inde= x 0 /  represented_port ethdev_port_id 3 / end

 

flow push 0 queue= 0

</Not working test-pmd commands>

&n= bsp;

On= ce I remove matching patterns for the inner packet headers( ipv4 / icmp) as= following, I can see the processed packets inside VMs using tcpdump.

&n= bsp;

<Working test-pmd commands>

=85

flow pattern_temp= late 0 create transfer relaxed no pattern_template_id 10  template rep= resented_port ethdev_port_id is 0 / eth  / ipv6 / end

=85

flow queue 0 crea= te 0 template_table 5 pattern_template 0 actions_template 0 postpone no pat= tern represented_port ethdev_port_id is 0 / eth  / ipv6   / = end actions raw_decap index 0 / raw_encap index 0 /  represented_port ethdev_port_id 3 / end

=85

</Working test-pmd commands>

&n= bsp;

Si= milar combination works when using the synchronous rte_flow API. Any commen= t or suggestion on this issue is much appreciated. Many thanks in advance.<= /span>

&n= bsp;

Be= st regards,

Ta= o

 

&n= bsp;

--_000_DB9P193MB17394A00CCEB00D137FA6264A3312DB9P193MB1739EURP_--