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 07CE943D0E for ; Fri, 22 Mar 2024 16:08:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 710F9402A7; Fri, 22 Mar 2024 16:08:44 +0100 (CET) Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02olkn2086.outbound.protection.outlook.com [40.92.48.86]) by mails.dpdk.org (Postfix) with ESMTP id 1791B40284 for ; Fri, 22 Mar 2024 16:08:42 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c3uMKzfTDCCIKb21r7Lku/gf/bXj5oAq3POvN08uxeT00QQfvrgjvrnMWp19SAQtEonBm6MOxRptFwMmTBM8M71QOfIP+oq5U/8pzF8ZmvKxR9THXHoVQFC6mO3DANnSb+veUJGxZqrHQ/jSfTXYL4r+RTjlNyAhEaCU96AMCLsROubxgb8udLPcOzDnbj53jZRG1SjjNobBduP42fCEC2hJl/Yg6D7ShCDrEoVDilpgBiiWf56Y+g16QKnqT/zG2wZC7pPQ23j73LLDW4RRXyT/E2JCCFd4MLnsDMl6WzeQCXm9MSp4NHoGJ8127/YPPT0w/Sd8pN7QgY7BeUmrfA== 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=wpYsoP4spP/SKEA3heTSTy8d4dyV1yyt5ry2Q6Msav4=; b=KxbbC6XqRld1s0+u4aUTw3Q1oCczdCbCNCJG6iF8F1wVC/kVJz1VuhnYbxrukrUYUAEuKaUWzx/Caq7Ql//NyQGWPU0IP/USdMbnvs0U/d1/cEFVaCM1TwccWnOtZG6ocI+L2HeyowAf/pIa/VI/jb22JptSFqUOVAki4jk8fAJmIV7Jkvtzt5xb+0/sW2hAN7Bdjj9d2rw3y/i6CaBHxJFhAuL9tYYSVw4fxl7HaPdT+Vz3GXIodMqpsg7YuzuxY6Ndnmu/DRviXqbGRT2xcxPchHY8BJmAdNC2GmR2VYmMBUydyJNLpejImfl8uTp0eFDsn6799nbDys38rIVzvA== 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=wpYsoP4spP/SKEA3heTSTy8d4dyV1yyt5ry2Q6Msav4=; b=SCtWKNm5hxgxnsxpmM13p40MjlMOhhIbAX89MRojUtP1a1YCJP7n08eccTQHQxp2WSfKy3/IC4ZdNQXXM9dy4Xger3m9Fy+jO3FYCg6CMqGnL0s1eb7sLRVpSCzZmXwsptkX4dVnBPJu5a5dD0N/G9071GT9foT4F129pRkfAAKMlqqQ9s2nK9DWNicezHiBnljNI7lbQ2cyPi2eDDeC5Aq7ClQfBa0K3ogwkufdS2PUzZTrcqwPCrQy34yqPb98D68DkWtHo1GueB1Ewnqbzvsz8S8jeaid9GieY9S85P/mdm+oejCGlkr/Du2bwTRoXkV/TBIQuUHbIjN5YCbqNw== Received: from DB9P193MB1739.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:24f::20) by AM0P193MB0707.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:16d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.15; Fri, 22 Mar 2024 15:08:40 +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 15:08:40 +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: AQHae6BPNEwcGktAFESopA2jvtTxHrFCkUNugAAAdQaAAQY17oAARUEj Date: Fri, 22 Mar 2024 15:08:40 +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: [+rURiSSgy2Hji7Jmine1Spmopq6CI1GX] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9P193MB1739:EE_|AM0P193MB0707:EE_ x-ms-office365-filtering-correlation-id: ec54a6d2-b188-403f-dca3-08dc4a81f50e x-ms-exchange-slblob-mailprops: BG3AXrlrvvrsPTJDEpWWGy24uyAizBFH3ZbnLwyBUR1MO047X+lOcf0v43itcXu/prSIr6/Teut1YUBrUATSgZtQNeug3eHwxZoj3CetdCksEXmRoWHb+y8p2nCTkEZQaZP1QuYL0MM/jc7KRc47MW7YVNaBdIxyuZRauZUAJGDlyanoH2guP6tVCFKSBvcaT2IYY+OryAKXyDj+M76fLYFZV3h4WdSX/rNUX2RTN3otLnLf21aZQaQOEMObnYiFJEXaVGduMNGeA9cilVuGhKvwHSMdgS0TeAQb0TbcWYeZgM+GzAVc7t0TfFFZSfdFyEY6D0OBY/+sZVcx624o79ZDJf6nvbFWDfuN2Yu+RP/GPhUNYTxbHvBdbKNrQu6vGACzKSPTLaKvHQOd5JBu4mNl/zevVDUIUpxNxGpBh6NK7tQ8Y6/lg5D1CJq3GKpQJYz0KjUdV/fbuOzh8LD88vPTl2rBI3icflAPP/c1dGcuhIuLv34u/uZJShD4Mm0pD4F4T6Uzo98fNDvBf02EIZP9+w+6yjUZ2AX/QgRR11A94IDwdOY9ylupkmYEWnnrKsIJp1NtJivfz1TlWbc905pPT5hGjPlYgxWQGyJZWGvju3BOTo0Jl6PLeHZzx9yc40oSKFDgHA5yll/scGBHspHi0IIM+pURjF/Hj7xo/xtDaHMIuJL4LxuKFsRwcy0SI72/6avfIUQqPIIiIzXcVWOj/zWM/ZwiJvL6quVHqfwsc9/vrAYxe8Aa/CHqG+Mv6x4a43OMqCzlIv42ndIrHYnKS+dDCEemkUC9P0t0DlhTkhKecAmy/Q== x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oq12XO85L7c0mC3W8DbwAKTLMrfipQi9jJ8W6QuNz+Z//6nG/TlmK6Zur20fuXyRlk0jvBJG8Kps+7bHXmwekWItsemuPx/EkvYko8ACg0o5txZATduuPrY0mGGFWXItmE4enVdIxSKt8Y4C7n4GDBpvtDbuxuxPCC6JJjRAmkhAMM/5aKJR77IfnVGyF+jyVLF2G3X7Xd2CyLgDRKFBYiPy6nkiPOm4BcX1QK2PggrvBoIal48HX5c44V9B4upaidwaNxA2Lq/09D/H1rS++oikVNeMPkd5zWdnDwn0/S4ZkdQ/vCIEDL7tJpdWe145QBabypXyss2enjK3XPLeoOhot4SenhNKyML9Y4h6z/b0eLfbNX8itvSrt4zqiVdehbS98guBWjtXCCZ/EH3HvbNBuvZbWflekfoaTa/A21P9CPQ7dvEJ7Kg8DAsJT2NbXEUvquOx7cT4JhYSNujYLT1Q4veLvqWnGJCzmYTWJLWGW/cUx8hDLD8cUXAUtP5nnRmjJyo2u70fiQgNsyWTzoN2ggKlGtpjXuBh6kFdyWVpOnbB52/kJ4acDpSWKT3pRhyakijXJnxQBAE0HzqE9/xRbMrbkVsotiljzsjZrXmo6slzOzthvPwymw91bOjykR+s1QxH0sJ3T5DH6Xrm9D3NGIspiC4vHBQlWJlXXX6znZSNN9BOR0DrRVZlMOvG x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?Pe6T3/AHcHZ9guHqCVDX+xW414/BaSmRWN4j8FkPveguc/5SbjJDAsEn?= =?Windows-1252?Q?qqXiLsLFIcIABLceeTR9EG8d/7Z13IxN+P7q+g9xPipsfgi8nFwLYGCW?= =?Windows-1252?Q?VbQ8kJz8sl3Fj2P+1NJG9R2yxCWv3Uee2d7vPTUgeJ6wD3UlkMz8b+hv?= =?Windows-1252?Q?9DM5zv1kYGC4pmOfdLGDwnS37RLrvd4WkXnD0WLMtrGqFoB6TvJe1XEd?= =?Windows-1252?Q?lTjks94HH7rqXkSVyHstqcKlmZlMzWOtMyG48Y51U1ipZHtr1SuWDqS8?= =?Windows-1252?Q?2DFaSMBEEH33UCRlzWkyaSr70rxYKoRs3/JH6VHnT3bzGA64WlhzX7YE?= =?Windows-1252?Q?XyT3XSO7wheNAZg018i74Zrco7D8e3mnc44JSpVkMQt83/ZoMd7YjKm/?= =?Windows-1252?Q?jnE63KGVlI8o6jDfkU37MNU6d4ktSSk7r0/0UBLP9amfxQNH7PzkKs2G?= =?Windows-1252?Q?kx1v8k6zocVokNSH0+HRk2IrJ1Q6MiCSG2P9gtRWvWBKDbIMcSwLJQkJ?= =?Windows-1252?Q?bsqEpSdvHamzGSkQHc5jiUE7f2fDJnNWap3WmqsjNHYIIo5StV8GZyG5?= =?Windows-1252?Q?hYdPw03jUz4EL3EX3eXOCBU5Jz4FedJ0aINy9U76jZpnmi9Ly6kuNsMr?= =?Windows-1252?Q?Q7L7fJJDSyCZ0ha9H12cAQi05U7BqY8DhXhJiGswOfn0hhDDaOab/nie?= =?Windows-1252?Q?GVVqN/Z7XWcZn00fVQBxxnxvvLCEo/B+43/oTj8q45zw2wR03zO1s1sM?= =?Windows-1252?Q?ol8QXdzG3Ci+WsYxRitu5yRBvkpDMbI552CzSKOpMx2mNRaXeGRe1wzT?= =?Windows-1252?Q?6S48m/1wN4LDII09yWE2k90PJSw3uUfe5TwZX3WGzzDr8hqIVivipPJQ?= =?Windows-1252?Q?+zryWwAitDhAh5XmUtQ0yH9+GvD6iLDWfxF8lU9mMyeC3FyQoF3STz6m?= =?Windows-1252?Q?GNa3Jmcb/drRg5mfrq7GbComzXki/19TieumJEGps15tqQb7EwMdgold?= =?Windows-1252?Q?BiYb4ef+PumZP3MsRF8vVZlmLLoHRFm5fVfZVQ+y50apdHkQ4ei9wbTN?= =?Windows-1252?Q?RZe3fYX2q+u6BWt2etPzn5mOB1DTE8vdTPJEDaaboRDvro+hGphVF8Vu?= =?Windows-1252?Q?XGpvss6htyCevHYMWmESZqunQmRX9K2/9lcdsMnN2c79eAW19FGw1/1B?= =?Windows-1252?Q?QcRWfQ5CuetvqLvULy3FhYA/P9s+k8FY/j/+A7JnzdzcBr1hW+EjOfNF?= =?Windows-1252?Q?JOQIR21AvhbY+swdxHtA4hNjWvgRdN+bQBaMZsMlayOGq05xdeLsER9q?= =?Windows-1252?Q?Qjl9bECV14p8rzjGYQkWobk73GKnkeVDvDy8anjrI+5/FV30?= Content-Type: multipart/alternative; boundary="_000_DB9P193MB173969AD647DBBFAC4F5B7F5A3312DB9P193MB1739EURP_" 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: ec54a6d2-b188-403f-dca3-08dc4a81f50e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 15:08:40.2330 (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: AM0P193MB0707 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_DB9P193MB173969AD647DBBFAC4F5B7F5A3312DB9P193MB1739EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Asaf, We generate incoming IPinIP packets by using our complex solution, but belo= w you can find a Python script to generate such packets to serve this purpo= se. I hope it is helpful to reproduce this issue. Thanks again. #!/usr/bin/python3 from scapy.all import * from scapy.layers.inet import Ether, UDP, ICMP from scapy.layers.inet6 import * ether =3D Ether() ether.src =3D "src mac" ether.dst =3D "dst mac" ether.type =3D 0x86DD ipv6 =3D IPv6() ipv6.src =3D "src ipv6 addr" ipv6.dst =3D "dst ipv6 addr" ipv6.nh =3D 4 pkt =3D ether / ipv6 / IP(src=3D"192.168.129.5",dst=3D"172.32.4.9") / ICMP(= type=3D8) print(pkt.show()) sendp(pkt, iface =3D"ens1f0np0") < /Code snippet to generate IPinIP packets > Cheers, Tao From: Tao Li Date: Friday, 22. March 2024 at 14:19 To: Asaf Penso , users@dpdk.org Subject: Re: Finer matching granularity with async template API 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_DB9P193MB173969AD647DBBFAC4F5B7F5A3312DB9P193MB1739EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Asaf,

 

We generate incomin= g IPinIP packets by using our complex solution, but below you can find a Py= thon script to generate such packets to serve this purpose. I hope it is he= lpful to reproduce this issue. Thanks again.

 

<Code snippet= to generate IPinIP packets>

#!/usr/bin/python3<= o:p>

from scapy.all impo= rt *

from scapy.layers.i= net import Ether, UDP, ICMP

from scapy.layers.i= net6 import *

 

ether =3D Ether()

ether.src =3D "= ;src mac"

ether.dst =3D "= ;dst mac"

ether.type =3D 0x86= DD

 

ipv6 =3D IPv6()

ipv6.src =3D "= src ipv6 addr"

ipv6.dst =3D "= dst ipv6 addr"

ipv6.nh =3D 4<= /o:p>

 

pkt =3D ether / ipv= 6 / IP(src=3D"192.168.129.5",dst=3D"172.32.4.9") / ICMP= (type=3D8)

 

print(pkt.show())

sendp(pkt, iface = =3D"ens1f0np0")

< /Code snipp= et to generate IPinIP packets >

 

Cheers,<= /span>

Tao

 

From: Tao Li <byteocea= n@hotmail.com>
Date: Friday, 22. March 2024 at 14:19
To: Asaf Penso <asafp@nvidia.com>, users@dpdk.org <users@dp= dk.org>
Subject: Re: Finer matching granularity with async template API=

Hellp Asaf,<= span style=3D"font-size:12.0pt">

 

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.

 

  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:

 

<Code = snippet to initialise pattern masks>

static const struct rte_flow_item_eth flow_item_eth_mask =3D {

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

};

 <= /p>

static const struct rte_flow_item_ipv6 flow_item_ipv6_dst_mask = =3D {

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

};

 <= /p>

static const struct rte_flow_item_ipv4 flow_item_ipv4_proto_mask = =3D {

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

};

 <= /p>

static const struct rte_flow_item_icmp flow_item_icmp_mask =3D {<= /span>

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

};

</Code= snippet to initialise pattern masks>

 

<Code = snippet to create pattern template>

  =             &nb= sp; // pattern template<= /span>

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

  =             &nb= sp;            =      [2] =3D {.type =3D RTE_FLOW_ITEM_TYPE_IPV6, .mask = =3D &flow_item_ipv6_dst_mask},<= o:p>

  =             &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,},

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

 

<Code = snippet to create patterns><= o:p>

  =             &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;

 

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

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

 

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

  =             &nb= sp; icmp_hdr.hdr.icmp_type =3D RTE_IP_ICMP_ECHO_REQUEST;

 

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

 

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

 

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

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

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

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

 

 

  =             &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;

 

  =             &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;

 

  =             &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;

 

  =             &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;

 

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

 

 

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

 

Best regards,

Tao

 

 

From: Asaf Penso <asaf= p@nvidia.com>
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 i= pv6 / 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

 

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 c= ommands>

port stop all

 =

flow configure 0 queues_number 4 queues_size 64 co= unters_number 0 aging_counters_number 0 meters_number 0 flags 0   = ;# PF0

 =

flow configure 1 queues_number 4 queues_size 64 co= unters_number 0 aging_counters_number 0 meters_number 0 flags 0

 =

flow configure 2 queues_number 4 queues_size 64 co= unters_number 0 aging_counters_number 0 meters_number 0 flags 0

 =

flow configure 3 queues_number 4 queues_size 64 co= unters_number 0 aging_counters_number 0 meters_number 0 flags 0  # PF1= V0

 =

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 i= s 66:9d:a7:fd:fb:43 type is 0x0800 / end_set

 =

flow actions_template 0 create transfer  acti= ons_template_id 10  template raw_decap index 0 / raw_encap index 0 / r= epresented_port / end mask raw_decap index 0 / raw_encap index 0 /  re= presented_port  / end

 =

flow template_table 0 create  group 0 priorit= y 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_tem= plate 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 inde= x 0 /  represented_port ethdev_port_id 3 / end

 =

flow push 0 queue 0

</Not working test-pmd = commands><= /p>

&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 comma= nds>

=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_tem= plate 0 actions_template 0 postpone no pattern represented_port ethdev_port= _id is 0 / eth  / ipv6   / end actions raw_decap index 0 / r= aw_encap index 0 /  represented_port ethdev_port_id 3 / end

=85

</Working test-pmd comm= ands>

&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_DB9P193MB173969AD647DBBFAC4F5B7F5A3312DB9P193MB1739EURP_--