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 93A0043E32 for ; Wed, 10 Apr 2024 10:17:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5DCF5402C5; Wed, 10 Apr 2024 10:17:51 +0200 (CEST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2102.outbound.protection.outlook.com [40.92.90.102]) by mails.dpdk.org (Postfix) with ESMTP id DE4444029E for ; Wed, 10 Apr 2024 10:17:49 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f8OAz0M4+9JGOxkFtAbiVUskhiR4AMb7cELeMe4ioCw2o66KW9uFufpWu45+Q2v9QBOV1zodaiGBlUwp4PQ5k4HW+4BdwzOXQdhqsKKgzVazVuf5gIinV2edzhd9rXxLHDcZKOPQ94x4InB/Omss9S0TK9Se7gZiKWQgOlqZ0D9kfNZDUOme4aZlMCQUv15uMkZI6w557vOeqW/lLfi5cDm5oES28dnOmSzEXKYfVQHLrsabb37qYHlfJu809n1JJlFLrZwSZ0b7t7SDYwN1vtZPaSxikFDL+5lB7RLWEg0wazp3U4gQQKKAyMAHEChg8S73724y07XUgG8Ix2ZN1Q== 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=3/sfQHWvtUe2x1w0Jq6R/SJBBQJkKXsBsC0f0lyGMBs=; b=Qy2pwGXvrHXt0EXuEH9xJzYKjH+fH8mKHWH3xP87jE6EUfrt8snaqBcYVEtNkC/i9Sa3IrvJ39ZNbh94b3eydxDHbUbisTUl5p8bWiVitO8h/Y7CipEoR6RnhZf81DRG49WYGxGYlu5+VfEI+V2E/eoLDqKfRTqqUacb83U97quHVDI1yS/+nzLPLYWsFsz6jHM5WXcKiSGUPsume/Id6hxw/jVVIg1BUWqht4w0nKLR2oTtfAdsahvHmTEvvpy7hq5gDymzBTZ1GpOGnkBcaxqodGL/XNhg4QIT7RpBsn7InSKp+y0ZSZ6TTyM635zw8dCluppeHReCC6L+to1XQg== 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=3/sfQHWvtUe2x1w0Jq6R/SJBBQJkKXsBsC0f0lyGMBs=; b=f+YeMvarhfJKj8myekvuIDQG2h7hO9SDmo1XrKxPqSBnGbHD/zhHKL0DdauPvx+J3AbBdBNFfQzNDgDXtBuY6gOzinItvfrLXVewtfVBFajYfgTxGJGLBl32JXJ6/OLjh7pEjreKVe2eQQk/JkMvJuWc1YTwawQbSBv1Gz5rO7StRE1IuSDHZ7CWrbRd+Fok5KekUVzAleYwR8J62CUkcsVIbYLf+mAlw5wif+C7yisAEGo79MgDo2pPC5A4kL2Q8wW5ahJy/tICrwVxSMeiAT28uK+952NmYpC9CEZGNBgpZpuwg+n+6vtaMdHmYLA8clCFpMsOrLfCfPwy7G3FSQ== Received: from DB9PR09MB4906.eurprd09.prod.outlook.com (2603:10a6:10:26e::13) by PR3PR09MB5316.eurprd09.prod.outlook.com (2603:10a6:102:177::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.55; Wed, 10 Apr 2024 08:17:48 +0000 Received: from DB9PR09MB4906.eurprd09.prod.outlook.com ([fe80::fb2e:e9f8:c453:c301]) by DB9PR09MB4906.eurprd09.prod.outlook.com ([fe80::fb2e:e9f8:c453:c301%6]) with mapi id 15.20.7409.042; Wed, 10 Apr 2024 08:17:48 +0000 From: Tao Li To: "users@dpdk.org" CC: "tao.li06@sap.com" Subject: Packets cannot reach host's kernel in multiport e-switch mode (mlx5 driver) Thread-Topic: Packets cannot reach host's kernel in multiport e-switch mode (mlx5 driver) Thread-Index: AQHaix4jMREohSPxmk6Gj3lNXdj4vw== Date: Wed, 10 Apr 2024 08:17:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [RY/0K9ivxnrz+Vg/8xv3SHseZWztn3I/] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9PR09MB4906:EE_|PR3PR09MB5316:EE_ x-ms-office365-filtering-correlation-id: 014cf181-2ab2-4c30-d2c6-08dc5936b527 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S3N0pDj5otaz3qQKxKeVgtccXumgTO8TMZo9/qPiNRA2Bp3bKRh8m6LVkKpRTyG0tPbnQ4+OnFqzWfi++w6rfraoR7qIStekPoJIzUQ/500reIPjGTFNrd6khkIi7cLoWNqeO/uXx8OAQ7wYYVOOnR2DVwc9EK1Dwn/sPoBQWCOzgdFYQPpoIJLJ4tZnNslbLu1mVoEwNTK9xd3BSraWLdxv+0iiYIRRrDhMCZ7LOWKAAe5qylz2ihxnaUThf7zaGARhsYMcKCpu7PYRbT9+XU3zBCYiHbKMjjvgL/U/YlvjgYWtjH5xP6o8X4a6tSqMhn7Ws6qnD0asP6HbjaJlZb6IFvLXHVwYT4HUXVzrTFRkCbID9GV3MTi6AFO7270yzze0HblZbl3C1cBDSJSqX9qb4BDwo215e0i8e4WKlhh+vb+Im3J/XKT74A/kolgH+Hq30bL8NgcU52GUpc4J3wat/UixNvwySxr9LWVWwPOumG5AxnSa/NvoHoFfYwJkdGhSxw5b2AMSsBkh+lClfxjo4tDH0xXei36yjklsdCHgN5oEB371fpJho6qCLMXO3n9U8HNddEQoR+11zSNA0eHyFK5pEcxJbxYXzAcqiuXSyAWOA2d2trjKirG//wLOgx8DI1HSB8mo70uYLc6x7z35FOkEib6Af9Z7ID5IYsmb+O80t+AMT8LbJ2aUQk3x x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?jI4uYa65hFhHwAH10iONzQOS42n3BaRjv/j/LXWZfkmyaLcfE85XmV20?= =?Windows-1252?Q?OHp9K3xsUZvCnhTAJC0LQr0KDZE5JiEtJMYfvz+sVjyH2B3vzaZu9778?= =?Windows-1252?Q?eBWMV4PtgBClevpwC+KP+hcIoX5dXF6kvZ6ZStTRtNzNoTYUKezUzgLN?= =?Windows-1252?Q?p6vjLWyss1ELBxHppISRPNMvhYjIJcEPZSb0E/utTkq9WNimvtb2eBMP?= =?Windows-1252?Q?U9Ua0GNhZ0P6XBUWO5lNnZc6lfkQFgjWEjOJV5VFJAASaPsqMiIZtnMU?= =?Windows-1252?Q?S9RtN8idUPJdPViw8h6aSyw7dT6e4Fz6NKGi/lhNJaWUCUcZMsDXsENQ?= =?Windows-1252?Q?zosr3E8wxJAcq9+xYoER1f+jQrN7zTnlO3TAJEaFAGyqtfVqj8x4hZus?= =?Windows-1252?Q?1jHVdyWWpaEiAmm0SBawtAD8dLZ6F+4ePOox4XycMoH+Yg3V9PUWKYck?= =?Windows-1252?Q?YPxvzDRx5HOaM6OHAIQ901/MepQzkNXOhjIX/a87F4odUh9vQ6MjUEAP?= =?Windows-1252?Q?dVS4kzdP3s86T4278dEPHClbxTxCxkeMaXSmdTxCILWDWn/R++2/3158?= =?Windows-1252?Q?yLYlEaoV11Uw2qEmrUbv+YKzYTXog4G0oI+zGvr/sJgkCEVuqvD5ZyOz?= =?Windows-1252?Q?fwnB343AOi3Pv0fLOGDyHGKWCl8qPHZMb/WzOYbjrDy4fV77rVNz3chO?= =?Windows-1252?Q?+Pun4e3sPfAxt935+xU+c+uLsZSgqTI2lL2td+y5bkRh4JgR9OFfYo3n?= =?Windows-1252?Q?l9aQ7XMf3tZfinj6JEsnI25CFVAOs/qjlwtLOgHUjeBcul6DF0n8qbDr?= =?Windows-1252?Q?tHZT3eH4qrj/sacvdxaLibDzt+bg+iMQ/q06W7/puja9Cbj9g3UyRthG?= =?Windows-1252?Q?hxpq0IvD8MbdvGxYkuckz0wJBJxvAhlTiOjRI+7x2IVp17oNFVuQrlXI?= =?Windows-1252?Q?R/loCfzwoilXmxiAkOhIwBvYaiijB6VEZcznYBH3W4yXvacToWYaJ1r0?= =?Windows-1252?Q?T5Zyypot/5VAPiwFMhLYObYbO+uusSdGOcReNq+AaH623LxvyCl9UX5s?= =?Windows-1252?Q?shogCd7yP71c9ctLn1+u6ieJwW9WYBY1B6woo/9fi4euE/oxWAFMOuOS?= =?Windows-1252?Q?M4/uYSV74tHIdN3TMT/EsLvYMFjj0LLrurf5Ee3Oi9fLeUoA1YFHiAIN?= =?Windows-1252?Q?v+SzlLE9JS1C2btX2YuZsrQnUciX1Z5Iqb3nrylKRkBl1fUG5vouhn5Z?= =?Windows-1252?Q?8p21Yc1fNuqsU0U+nAIM43dN7o35yCcJmiucbt05aIcZ3x8m3Xt+aepg?= =?Windows-1252?Q?7evrInrjfkOaaNPVRfXEiH3NW6+A/jPRAPD463eQGC2u3myg?= Content-Type: multipart/alternative; boundary="_000_DB9PR09MB4906DE68812A6B983FEC8CF9A3062DB9PR09MB4906eurp_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR09MB4906.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 014cf181-2ab2-4c30-d2c6-08dc5936b527 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2024 08:17:48.1914 (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: PR3PR09MB5316 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_DB9PR09MB4906DE68812A6B983FEC8CF9A3062DB9PR09MB4906eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, I am currently experimenting with a feature newly supported by DPDK 23.11, = known as "multiport e-switch" to improve communication reliability on the server side. = During the trials, I encountered an issue in which activating multiport e-s= witch mode on the NIC disrupts the hypervisor=92s software running on the s= econd PF interface (PF1). More specifically, packets coming from the second= PF (PF1) cannot be delivered to hypervisor=92s kernel network stack, right= after setting the multiport e-switch mode for the NIC as guided in documen= tation. A snapshot of the packet trace comparison on the second PF (PF1, en= s2f1np1) before and after setting the multiport e-switch mode is attached h= ere. Packets marked with the gray color/italic in the second trace are mis= sing under the multiport e-switch mode. --------- ConnectX-6 Dx with firmware version 22.39.1002 Linux kernel version: 6.6.16 DPDK: 23.11 ---------- ---------- 14:37:24.835716 04:3f:72:e8:cf:cb > 33:33:00:00:00:01, ethertype IPv6 (0x86= dd), length 78: fe80::63f:72ff:fee8:cfcb > ff02::1: ICMP6, router advertise= ment, length 24 14:37:28.527829 90:3c:b3:33:83:fb > 33:33:00:00:00:01, ethertype IPv6 (0x86= dd), length 78: fe80::923c:b3ff:fe33:83fb > ff02::1: ICMP6, router advertis= ement, length 24 14:37:28.528359 04:3f:72:e8:cf:cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 94: fe80::63f:72ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.= 179: Flags [S], seq 2779843599, win 33120, options [mss 1440,sackOK,TS val = 1610632473 ecr 0,nop,wscale 7], length 0 // link-local addresses are used 14:37:29.559918 04:3f:72:e8:cf:cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 94: fe80::63f:72ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.= 179: Flags [S], seq 2779843599, win 33120, options [mss 1440,sackOK,TS val = 1610633505 ecr 0,nop,wscale 7], length 0 14:37:30.583925 04:3f:72:e8:cf:cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 94: fe80::63f:72ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.= 179: Flags [S], seq 2779843599, win 33120, options [mss 1440,sackOK,TS val = 1610634529 ecr 0,nop,wscale 7], length 0 ---------- ---- ------ 16:09:40.375865 90:3c:b3:33:83:fb > 33:33:00:00:00:01, ethertype IPv6 (0x86= dd), length 78: fe80::923c:b3ff:fe33:83fb > ff02::1: ICMP6, router advertis= ement, length 24 16:09:40.376473 fa:e4:cf:2d:11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 94: fe80::f8e4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83fb= .179: Flags [S], seq 3409227589, win 33120, options [mss 1440,sackOK,TS val= 2302010436 ecr 0,nop,wscale 7], length 0 16:09:40.376692 90:3c:b3:33:83:fb > fa:e4:cf:2d:11:b9, ethertype IPv6 (0x86= dd), length 94: fe80::923c:b3ff:fe33:83fb.179 > fe80::f8e4:cfff:fe2d:11b9.3= 6168: Flags [S.], seq 3495571820, ack 3409227590, win 63196, options [mss 9= 040,sackOK,TS val 1054058675 ecr 2302010436,nop,wscale 9], length 0 16:09:40.376711 fa:e4:cf:2d:11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 86: fe80::f8e4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83fb= .179: Flags [.], ack 1, win 259, options [nop,nop,TS val 2302010436 ecr 105= 4058675], length 0 16:09:40.376865 fa:e4:cf:2d:11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86= dd), length 193: fe80::f8e4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83f= b.179: Flags [P.], seq 1:108, ack 1, win 259, options [nop,nop,TS val 23020= 10436 ecr 1054058675], length 107: BGP 16:09:40.376986 90:3c:b3:33:83:fb > fa:e4:cf:2d:11:b9, ethertype IPv6 (0x86= dd), length 86: fe80::923c:b3ff:fe33:83fb.179 > fe80::f8e4:cfff:fe2d:11b9.3= 6168: Flags [.], ack 108, win 124, options [nop,nop,TS val 1054058676 ecr 2= 302010436], length 0 ---- ------ Attempts to ping from another directly connected host to this hypervisor al= so resulted in incoming ICMP packets not being captured, which is reproduci= ble in another testing environment setup. In the end, I was able to restore= communication on the second PF by using a vdev TAP device and performing p= acket forwarding between the TAP device and PF1, as shown in our public exa= mplary code. Enabling the isolation mode on PF1 by starting testpmd or programmably usin= g `rte_flow_isolate()` leads to no change from the behavior as described ab= ove, but only affects whether packets can be captured and processed by the = DPDK application. ---- ------ sudo ./dpdk-testpmd -a 3b:00.0,dv_flow_en=3D2,dv_esw_en=3D1,fdb_def_rule_en= =3D1,representor=3Dpf0-1vf0 -- -i --rxq=3D1 --txq=3D1 --flow-isolate-all ---- ------ Any experience sharing or comment on the above described issue is very appr= eciated. Thanks a lot in advance. Best regards, Tao Li --_000_DB9PR09MB4906DE68812A6B983FEC8CF9A3062DB9PR09MB4906eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi All,=

 

I am currently experimenting w= ith a feature newly supported by DPDK 23.11, known as "= multiport e-switch" to improve communication reliability on the serv= er side. During the trials, I encountered an issue in which activating mult= iport e-switch mode on the NIC disrupts the hypervisor=92s software running= on the second PF interface (PF1). More specifically, packets coming from the second PF (PF1) cannot be delivered to hypervisor=92s kernel network stack, rig= ht after setting the multiport e-switch mode for the NIC as guided in documentation. A snap= shot of the packet trace comparison on the second PF (PF1, ens2f1np1) befor= e and after setting the multiport e-switch mode is attached here.  Pac= kets marked with the gray color/italic in the second trace are missing under the multiport e-switch mode.<= span style=3D"color:#212121">

 

----<test environment>--= ---

ConnectX-6 Dx with firmware version 22.39.1002

Linux kernel version: 6.6.16

DPDK: 23.11<= o:p>

----</test environment>-= -----

 

----<packet trace after setting multiport e-switch mode>------

14:37:24.835716 04:3f:72:e8:cf= :cb > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: fe80::63f:7= 2ff:fee8:cfcb > ff02::1: ICMP6, router advertisement, length 24

 

14:37:28.527829 90:3c:b3:33:83= :fb > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: fe80::923c:= b3ff:fe33:83fb > ff02::1: ICMP6, router advertisement, length 24<= span style=3D"color:#212121">

 

14:37:28.528359 04:3f:72:e8:cf= :cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 94: fe80::63f:7= 2ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.179: Flags [S], seq 2779= 843599, win 33120, options [mss 1440,sackOK,TS val 1610632473 ecr 0,nop,wscale 7], length 0 // link-local addresses are u= sed

 

14:37:29.559918 04:3f:72:e8:cf= :cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 94: fe80::63f:7= 2ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.179: Flags [S], seq 2779= 843599, win 33120, options [mss 1440,sackOK,TS val 1610633505 ecr 0,nop,wscale 7], length 0

 

14:37:30.583925 04:3f:72:e8:cf= :cb > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 94: fe80::63f:7= 2ff:fee8:cfcb.54096 > fe80::923c:b3ff:fe33:83fb.179: Flags [S], seq 2779= 843599, win 33120, options [mss 1440,sackOK,TS val 1610634529 ecr 0,nop,wscale 7], length 0

----</packet trace after setting multiport e-switch mode>------

 

----<packet trace before setting multiport e-switch mode> ------

16:09:40.375865 90:3c:b3:33:= 83:fb > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: fe80::923= c:b3ff:fe33:83fb > ff02::1: ICMP6, router advertisement, length 24

 

16:09:40.376473 fa:e4:cf:2d:= 11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 94: fe80::f8e= 4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83fb.179: Flags [S], seq 3= 409227589, win 33120, options [mss 1440,sackOK,TS val 2302010436 ecr 0,nop,wscale 7], length 0

 

16:09:40.376692 90:3c:b3:= 33:83:fb > fa:e4:cf:2d:11:b9, ethertype IPv6 (0x86dd), length 94: fe80::= 923c:b3ff:fe33:83fb.179 > fe80::f8e4:cfff:fe2d:11b9.36168: Flags [S.], s= eq 3495571820, ack 3409227590, win 63196, options [mss 9040,sackOK,TS val 1054058675 ecr 2302010436,nop,wscale 9], l= ength 0

 

16:09:40.376711 fa:e4:cf:2d:= 11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 86: fe80::f8e= 4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83fb.179: Flags [.], ack 1= , win 259, options [nop,nop,TS val 2302010436 ecr 1054058675], length 0<= /span>

 

16:09:40.376865 fa:e4:cf:2d:= 11:b9 > 90:3c:b3:33:83:fb, ethertype IPv6 (0x86dd), length 193: fe80::f8= e4:cfff:fe2d:11b9.36168 > fe80::923c:b3ff:fe33:83fb.179: Flags [P.], seq= 1:108, ack 1, win 259, options [nop,nop,TS val 2302010436 ecr 1054058675], length 107: BGP

 

16:09:40.376986 90:3c:b3:= 33:83:fb > fa:e4:cf:2d:11:b9, ethertype IPv6 (0x86dd), length 86: fe80::= 923c:b3ff:fe33:83fb.179 > fe80::f8e4:cfff:fe2d:11b9.36168: Flags [.], ac= k 108, win 124, options [nop,nop,TS val 1054058676 ecr 2302010436], length 0

----</packet trace before setting multiport e-switch mode> ------

 

Attempts to ping from another directly connec= ted host to this hypervisor also resulted in incoming ICMP packets not bein= g captured, which is reproducible in another testing environment setup. In = the end, I was able to restore communication on the second PF by using a vdev TAP device and performing packet forwardi= ng between the TAP device and PF1, as shown in our public examplary code.

 

Enabling the isolation mode on PF1 by startin= g testpmd or programmably using `rte_flow_isolate()` leads to no change fro= m the behavior as described above, but only affects whether packets can be = captured and processed by the DPDK application.

----<command to start tes= tpmd> ------

sudo ./dpdk-testpmd -a 3b:00= .0,dv_flow_en=3D2,dv_esw_en=3D1,fdb_def_rule_en=3D1,representor=3Dpf0-1vf0 = -- -i --rxq=3D1 --txq=3D1 --flow-isolate-all

----</command to start te= stpmd> ------

 

Any experience sharing or comment on the abov= e described issue is very appreciated. Thanks a lot in advance.<= /span>

 

Best regards,

Tao Li

 

 

 

--_000_DB9PR09MB4906DE68812A6B983FEC8CF9A3062DB9PR09MB4906eurp_--