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 B9FFAA0032; Tue, 12 Jul 2022 08:05:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EB0ED41109; Tue, 12 Jul 2022 08:05:39 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60136.outbound.protection.outlook.com [40.107.6.136]) by mails.dpdk.org (Postfix) with ESMTP id EB4BA410EF for ; Tue, 12 Jul 2022 08:05:38 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fzHC0hc0Hoi110Gf14JhiQaLtVrmDZEXLqqLP3g8ayIkv5I5xlWuHEElRW5eVighj98wykWTvDzDWhbKjLChM8YXkNXtxMhURAIb3dsPIpej/Ql9Iwrl7jMENZRWho3lUpbETJgc5fVZSOJOOUueg97xUYYcXppBMY8LoVrmdOangOMfFK19Z6hJ3DeiMP+5a4OBeDcY4kSEPxx+9Bbushqz+gJ1zwXA5nc4zz7h2jjVaxv8pG2gOHNl0HoooH31Li9ONrWmquSibfg7H9IK0U4Diqfh9PENnmFvusXG2bFLd9xUThPEn4BBiRB8jruZhIh0ZWru1LXc2cEJMIG1sQ== 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=e3GvnPe9b1g/w3FfYOod75ROsGh9L2KF3qnTFABtbe0=; b=bnSKNSAS34vP8i/TD5E+cOsXZf/HaRIrpc6D+pu50lYaKJzYd/gXmpiGZPn3zXngKE8IsgSlJubiE4zkIuc5lLz43qgN61Gs30b/96VXNQ/QTLlllxBK7uSeqNbld7uLuXJxi4ZQXZkBps7p/kMt+QlIzbyQdFXLOHKQ8PLtNdBXo8L9KdLaBfef02TzeZWHGTKpdBJSF3wx94n+83eIb3NU0w98hoEy5uweGYzGpMZqbymHtoUj8aFeorcnOCUCHilQ2699t/LwvVXcJ5o1sarMzb6wUo7rzMid54a8UMp4MqGbgl8nu3p+A7ccVfEUEhGqj7KbBP/n3lv2DhtKaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=radware.com; dmarc=pass action=none header.from=radware.com; dkim=pass header.d=radware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radwareil.onmicrosoft.com; s=selector1-radwareil-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e3GvnPe9b1g/w3FfYOod75ROsGh9L2KF3qnTFABtbe0=; b=Vonb9n1ojCuu8wwLegXwkSCTxRP4TqtmcMDAop+ow4Tt+Ep+peuUKliXHLoFw+iiOJxYSqnR5iWHR4mxg4z2P4PZ6OToDGkjGOHE8cb7b1psTl84PCjy5gGbP6BBUAjkdQYHmP/fR4iUgAuGdxm7hVshk1c+P+eIp91jZWGIjyM= Received: from DB9PR01MB9980.eurprd01.prod.exchangelabs.com (2603:10a6:10:303::11) by HE1PR01MB3899.eurprd01.prod.exchangelabs.com (2603:10a6:7:9a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.23; Tue, 12 Jul 2022 06:05:33 +0000 Received: from DB9PR01MB9980.eurprd01.prod.exchangelabs.com ([fe80::2de1:7a71:a22:9413]) by DB9PR01MB9980.eurprd01.prod.exchangelabs.com ([fe80::2de1:7a71:a22:9413%8]) with mapi id 15.20.5417.026; Tue, 12 Jul 2022 06:05:33 +0000 From: Asaf Sinai To: "dev@dpdk.org" Subject: DPDK 19.11.3 with multi processes and external physical memory: unable to receive traffic in the secondary processes Thread-Topic: DPDK 19.11.3 with multi processes and external physical memory: unable to receive traffic in the secondary processes Thread-Index: AdiVrw8m5p6IAIoqT3avkRMDulIOVw== Date: Tue, 12 Jul 2022 06:05:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=Radware.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89e204fa-9c05-4c07-6857-08da63cc8830 x-ms-traffictypediagnostic: HE1PR01MB3899:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rwFpLHKCN6mGvTz/CyEfsoUzMGpmpbcAWadV17/8fDfZ0JA30ekSPsySRrOAxyhuGfa3nM+7+E65Q0m/sqpmSbpkzHz2pTn8jaUJoN0t72T0VVoL8KFTHICZ62pAlCm15OW3GelWuCslGRgzTGFfE9D+lP16ruKNHtJw1e6O46C7P4A6mOJ0Sp3Qysu2TP10WCTiXFemkhE5TcfVT66JgFUfIFfX5lj1Ve2FhHSmUbFSSLHMKhfcU/WYEom8my7axUSVqBWaojnGQg/zEPj/tIdRO2UHVh97hu4tDszIqK3+F4NUVa3bw6gcV06f+fwFUuzF7D8yBwmld7vscxSVh6k1+N1PTDr6VHsM0QAjCPoXpntnyMmDtHdrQ3aH2cIDnMcpdLAreaI1Z/y5z7a5R2iw20Rs8SKxDERQdxtU5yIfcB5RRIEyCeteJL/cL4GrJmurXZTg5flPCNrVFViqEe8l3qnuPgOcqarVWX264Oxa1IzcewLrwT4z9SaUuxz4R+cLTx+D5sa9MsTtIzEP/G/nAuU5eiWiEcFY8xQaObw/ZITshBR76CkywoW+LKCvJIdiBoLEcbsa03YohouRmFUUhkGgVbJaYDBurpCT/cQSw2XzRjq+Dr5aiAzBcysKlh0shGlsqbNGuQoSfiZMdjlUkPeOuYNwmtalbMGjQBLX769zQqttZXSmL8DBdDJeDPbmdmHzacddEr7HZBC0/Pc7JtY8blbfUUrx7UL4f3EcI93YRxX2eMfMy+a/Dk8KZP1pYpTKap8GXW/6cZ4jiJmIBMv0S6iNSSU1aYstBjCQKQ+Kn3RvigEz9TnBuHT2kp82kEw/pXaZem8mHJqkwqtAsRvE2XPNgEeGSuvs6XvWoV7XhpqSm0SGjBCs9pGb9NTg4/hkt9Yi+N+uVqh7T7n5LV1qb2QL33G8tI1kOoY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR01MB9980.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(38100700002)(9686003)(26005)(7696005)(166002)(41300700001)(2906002)(52536014)(8936002)(33656002)(9326002)(5660300002)(55016003)(21615005)(6506007)(64756008)(8676002)(122000001)(478600001)(66946007)(86362001)(76116006)(966005)(38070700005)(71200400001)(83380400001)(66556008)(66446008)(186003)(6916009)(316002)(66476007)(131040200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?y0qytuECL3uHu+ocN2iGIffKU/5ZqmRJon3U1l8tM/lzdb1hZL1AhMw0cLUp?= =?us-ascii?Q?w5+CWpHDAUuNOhvVntc/gRNiLu+rT7gQVsIp7+IBkv5ZIABmvZELfYoFQZ4j?= =?us-ascii?Q?PnVdXEHJkM/5qSAgUoOU+bx0M+O4sprzAlXIGB8VT3g1gQlqu87hg64P3a/Q?= =?us-ascii?Q?uw5Xh1bq1ZswEm1WM+2JhZynph1lVlZEXJEUztsabSecOzDrmfzCip8LgP5O?= =?us-ascii?Q?jNWl91/bvY3A1NfssL5IMAMFfmohl2UDRWFJLNHa3aVdRdndN0qB1IPQAgnk?= =?us-ascii?Q?agpMigJF5fwNWm4W4udLg1DD/QLuMurlTG0UyrAfqGaZgI2i/dxUs+RH23te?= =?us-ascii?Q?/j3uaIYRrTjpAwjfG/WatfNiGyCJ7zfdxN/CIysS/4Y0tZg3Ik3IXltrImKS?= =?us-ascii?Q?X1vaAbISckkbEbWNeO0PvXqJ6Yfe4qkPWhkaLMNQXpo920ZK0Kv1WyT0gIOx?= =?us-ascii?Q?3Y0tWg9V8bEpwl09+fte3avYsjwBumGvyreySYDuI5Bh1fo+d2rSmC4Z50lz?= =?us-ascii?Q?ZxRpckVAvQGi1ktXJIEB1aga9mzCNOeaBmDkOz98SNuShsl9xpZ7B7ZtfBJB?= =?us-ascii?Q?LK9nBU/YYsAYzLhUQJbfdD5wss8vHkcQ2lh/6SbyXNNBdCvWFjRXiOUFFR+b?= =?us-ascii?Q?6nweOFs+dSqoqGzVL+DJFU8F/j5ZC5pBSj16fiEuAT+0CFlCeXPQ9esqUme0?= =?us-ascii?Q?74O8caaNGi2RUkB3CufPBdmoCUDis6475OXolWK0Kh0GB8cJyecapDuzfgQY?= =?us-ascii?Q?4R8qVraHQcMSgTAXEZcuReGjtyYA2gTK/mQQG1ZisAVy8EfPSuil0GWlXNTY?= =?us-ascii?Q?62FVw2HuqN81PeN7OLl48gCIEG7TyHQlu4Yp5fUlDU2mm+thkYKP4ZXHRipx?= =?us-ascii?Q?UjKQXi8yTtOK2eihUZgIomqk5YzLKBLaGWV1sDaYOfryGG9qaA7LbFngR8Ki?= =?us-ascii?Q?Zc9ayXEv3quB/w0GKcGzk80M7BDfpDWkUpVS+ZeezaiDDwwquCxclXNyIZWN?= =?us-ascii?Q?E/EyEy6ScTDDbfxsQ9eiPBVTWgmDl7Iw6qcOBx9RUIfdJgPQQDhrXG5OWGKX?= =?us-ascii?Q?GGzI0ErN1qcyRFRW0oxUeLON1SOPhtUr7gkuYjTOcoHXVztrEJ9d1Srwh3X+?= =?us-ascii?Q?hkbuz6tNU1ZSxAFoflDXoK4GOrg9+vXbAcDIZXAtvLK1hSGh6Q8T0sRVNS37?= =?us-ascii?Q?/NuKYZSFd7m6ksgM2atz2RJjj5ZfjgtUsp4+hH4ubN/xwEXhjxHrbIeBG7xc?= =?us-ascii?Q?ebzDQwPMQFSNOx3ceoiLM+dM1tcfI1y+Az5J/O7Kq/EEo5z0ehRyElDX/aO8?= =?us-ascii?Q?K54ItkXteggfYqIb5UQeo/2kjRjBr3FNzVBCHNcL4kQFVriDfk5wXy/6h4V7?= =?us-ascii?Q?jD4/2TbcXgtoTP5d2oMmWSxVmonFeb+lnObpFfgU8UQqBE7y9Mob/Mf+egCP?= =?us-ascii?Q?cWg+ymzpkCFODe1rxNZbcM1zNDhaqBfqBQTd4GUyEY03nqQRFbq1uBPQzOUw?= =?us-ascii?Q?WkawNvx8bZwoKvBYhpTj57nIP1s1J2N7P2FUk8UdJxSRZ8T1C06MC9ueXEmy?= =?us-ascii?Q?VRxFICoUq1UR5Wug38QPy3QGITvuUqWjKA0qjp3J?= Content-Type: multipart/alternative; boundary="_000_DB9PR01MB9980511CA0952BD4DF089316CC869DB9PR01MB9980eurp_" MIME-Version: 1.0 X-OriginatorOrg: radware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR01MB9980.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89e204fa-9c05-4c07-6857-08da63cc8830 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2022 06:05:33.5542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ae4e000-b5d0-4f48-a766-402d46119b76 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8cnjxE+oX8xw8x9fc/3HIugBp10SCvjkwxTYlFy3Xf++1MRrOROaDLHwzFcAafys7WFCFAb+2X+7TnUoaCLD2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB3899 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --_000_DB9PR01MB9980511CA0952BD4DF089316CC869DB9PR01MB9980eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We run DPDK 19.11.3 with multi processes. When using external memory for DPDK (instead of huge pages), we are unable = to receive traffic in the secondary processes. * We have external physical memory regions (excluded from Linux): [ULP-NG]# cat /proc/cmdline console=3DttyS0,19200 isolcpus=3D1-127 smp_affinity=3D1 root=3D/dev/ram0 rw= mode=3Dr net.ifnames=3D0 biosdevname=3D0 systemd.show_status=3D0 memmap=3D0x1000000!0x60000000 memmap=3D0x90000000!0x800000000 memmap=3D0x90= 000000!0x1800000000 quiet cloud-init=3Ddisabled * We make all DPDK initializations in the primary process, including ma= pping the mentioned memory regions via "/dev/mem". After these memory mapping, we register the external memory, as described i= n http://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#support-= for-externally-allocated-memory, and allocate memory pools: ... /* Map physical to virtual */ int memFd =3D open("/dev/mem", O_RDWR); extMemInfo[i].pageSize =3D pPagesInfo->maxPageSize; extMemInfo[i].memRegSize =3D 0x0000000080000000; extMemInfo[i].memRegAddr =3D mmap(NULL, extMemInfo[i].memRegSize, PROT_READ= | PROT_WRITE, MAP_SHARED, memFd, memRegPhysAddr[i]); /* Create heap */ sprintf(extMemInfo[i].heapName, "extMemHeapSocket_%u", i); rv =3D rte_malloc_heap_create(extMemInfo[i].heapName); /* Save heap socket ID */ rv =3D rte_malloc_heap_get_socket(extMemInfo[i].heapName); extMemInfo[i].socketId =3D rv; /* Add memory region to heap */ rv =3D rte_malloc_heap_memory_add(extMemInfo[i].heapName, extMemInfo[i].mem= RegAddr, extMemInfo[i].memRegSize, NULL, 0, extMemIn= fo[i].pageSize); ... /* Allocate memory pool */ memPool =3D rte_mempool_create(poolName, nbufs, DPDK_MBUF_SIZE, poolCacheSi= ze, sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init, NULL, und_pktmbuf_init, NULL, extMemInfo[i].socketId= , DPDK_NO_FLAGS); ... Please note, that during calls to "rte_malloc_heap_memory_add", we see the = following warnings: EAL: WARNING! Base virtual address hint (0x2101005000 !=3D 0x7ffff4627000) = not respected! EAL: This may cause issues with mapping memory into secondary processes EAL: WARNING! Base virtual address hint (0x210100b000 !=3D 0x7ffff4619000) = not respected! EAL: This may cause issues with mapping memory into secondary processes And after executing "rte_mempool_create", physical addresses of the allocat= ed memory zones are bad: [Jul 12 12:02:17] [1875] extMemConfig: heapName=3DextMemHeapSocket_0, socke= tId=3D256, memRegAddr=3D0x7fff58000000, memRegSize=3D2415919104, pageSize= =3D2097152 [Jul 12 12:02:18] [1875] memZone: name=3DMP_ndPool_0, socket_id=3D256, vadd= r=3D0x7fffe7e7bec0-0x7fffe7ffffc0, paddr=3D0xffffffffffffffff-0x1840ff, len= =3D1589504, hugepage_sz=3D2MB * In the next step, we spawn the secondary processes from the primary o= ne, using fork(). This way, all DPDK data and memory mappings are the same on all processes. = For example: Mapping in primary process: cat /proc/1875/maps ... 7ffec8000000-7fff58000000 rw-s 1800000000 00:06 5 /d= ev/mem 7fff58000000-7fffe8000000 rw-s 800000000 00:06 5 /d= ev/mem ... Mapping in secondary process: cat /proc/2676/maps ... 7ffec8000000-7fff58000000 rw-s 1800000000 00:06 5 /d= ev/mem 7fff58000000-7fffe8000000 rw-s 800000000 00:06 5 /d= ev/mem ... * Unfortunately, when traffic is received by the secondary processes, w= e see the following printout on the primary process: i40e_dev_alarm_handler(): ICR0: malicious programming detected * Additionally, we saw no example of using external physical shared mem= ory on secondary processes. DPDK test applications show usage of anonymous private memory on the primar= y process only. What are we missing? Can you please advise? Thanks, Asaf [Radware] Asaf Sinai ND SW Engineer Email: asafsi@radware.com T:+972-72-3917050 M:+972-50-6518541 F:+972-3-6488662 [Check out the latest and greatest from Radware] www.radware.com [Blog] [https://www.radware.com/images/signatur= e/linkedin.jpg] [https://www.ra= dware.com/images/signature/twitter.jpg] [you= tube] Confidentiality note: This message, and any attachments to it, contains pri= vileged/confidential information of RADWARE Ltd./RADWARE Inc. and may not b= e disclosed, used, copied, or transmitted in any form or by any means witho= ut prior written permission from RADWARE. If you are not the intended recip= ient, delete the message and any attachments from your system without readi= ng or copying it, and kindly notify the sender by e-mail. Thank you. P Please consider your environmental responsibility before printing this e-= mail --_000_DB9PR01MB9980511CA0952BD4DF089316CC869DB9PR01MB9980eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We run DPDK 19.11.3 with multi processes.=

When using external memory for DPDK (instead of huge= pages), we are unable to receive traffic in the secondary processes.<= /o:p>

 

  • We have external physical memory regions (excluded from Linux):<= /o:p>

 

[ULP-NG]# cat /proc/cmdline=

console=3DttyS0,19200 isolcpus=3D1-127 smp_af= finity=3D1 root=3D/dev/ram0 rwmode=3Dr net.ifnames=3D0 biosdevname=3D0 syst= emd.show_status=3D0

memmap=3D0x1000000!0x60000000 memmap=3D0x90000000!0x800000000 memmap=3D0= x90000000!0x1800000000 quiet cloud-init=3Ddisabled

 

  • We make all DPDK initializations in the primary process, including ma= pping the mentioned memory regions via “/dev/mem”.

After these memory mapping, we register the e= xternal memory, as described in http://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#support-fo= r-externally-allocated-memory, and allocate memory pools:

 

...

/* Map physical to virtual */

int memFd =3D open("/dev/mem", O_RDWR);

extMemInfo[i].pageSize   =3D pPagesInfo->maxPageSize= ;

extMemInfo[i].memRegSize =3D 0x0000000080000000;

extMemInfo[i].memRegAddr =3D mmap(NULL, extMemInfo[i].memRegSize,= PROT_READ | PROT_WRITE,

           = ;            &n= bsp;     MAP_SHARED, memFd, memRegPhysAddr[i]);

 

/* Create heap */

sprintf(extMemInfo[i].heapName, "extMemHeapSocket_%u", = i);

rv =3D rte_malloc_heap_create(extMemInfo[i].heapName);=

 

/* Save heap socket ID */

rv =3D rte_malloc_heap_get_socket(extMemInfo[i].heapName);

extMemInfo[i].socketId =3D rv;

 

/* Add memory region to heap */

rv =3D rte_malloc_heap_memory_add(extMemInfo[i].heapName, extMemI= nfo[i].memRegAddr,

           = ;            &n= bsp;        extMemInfo[i].memRegSize, NU= LL, 0, extMemInfo[i].pageSize);

...

/* Allocate memory pool */

memPool =3D rte_mempool_create(poolName, nbufs, DPDK_MBUF_SIZE, p= oolCacheSize,

           = ;            &n= bsp;     sizeof(struct rte_pktmbuf_pool_private),<= /o:p>

           = ;            &n= bsp;     rte_pktmbuf_pool_init, NULL,=

           = ;            &n= bsp;     und_pktmbuf_init, NULL, extMemInfo[i].socketId= , DPDK_NO_FLAGS);

...

 

Please note, that during calls to “<= span style=3D"font-family:"Courier New"">rte_malloc_heap_memory_a= dd”, we see the following warnings:

 

EAL: WARNING! Base virtual addre= ss hint (0x2101005000 !=3D 0x7ffff4627000) not respected!=

EAL:    This may cause issues = with mapping memory into secondary processes

EAL: WARNING! Base virtual addre= ss hint (0x210100b000 !=3D 0x7ffff4619000) not respected!=

EAL:    This may cause issues = with mapping memory into secondary processes

 

And after executing “rte_mempool_create”, = physical addresses of the allocated memory zones are bad:

 

[Jul 12 12:02:17] [187= 5] extMemConfig: heapName=3DextMemHeapSocket_0, socketId=3D256, memRegAddr= =3D0x7fff58000000, memRegSize=3D2415919104, pageSize=3D2097152

[Jul 12 12:02:18] [187= 5] memZone: name=3DMP_ndPool_0, socket_id=3D256, vaddr=3D0x7fffe7e7bec0-0x7= fffe7ffffc0, paddr=3D0xffffffffffffffff-0x1840ff= , len=3D1589504, hugepage_sz=3D2MB

 

  • In the next step, we spawn the secondary processes from the primary o= ne, using fork().

This way, all DPDK data and memory mappings a= re the same on all processes. For example:

 

Mapping in primary pro= cess:

cat /proc/1875/maps

...

7ffec8000000-7fff58000000 rw= -s 1800000000 00:06 5         =             &nb= sp;  /dev/mem

7fff58000000-7fffe8000000 rw= -s 800000000 00:06 5         &= nbsp;           &nbs= p;   /dev/mem

...

 

Mapping in secondary p= rocess:

cat /proc/2676/maps

...

7ffec8000000-7fff58000000 rw= -s 1800000000 00:06 5         =             &nb= sp;  /dev/mem

7fff58000000-7fffe8000000 rw= -s 800000000 00:06 5         &= nbsp;           &nbs= p;   /dev/mem

...

 

  • Unfortunately, when traffic is received by the secondary processes, w= e see the following printout on the primary process:

 

i40e_dev_alarm_handler(): ICR0: malicious programming detected

 

  • Additionally, we saw no example of using external physical shared mem= ory on secondary processes.

DPDK test applications show usage of anonymou= s private memory on the primary process only.

 

What are we missing?

Can you please advise?

 

Thanks,

Asaf

 

=3D"Radware"

Asaf Sinai
ND SW Engineer
Email: asafsi@radware.com

T:+972-72-3917050
M:+972-50-6518541
F:+972-3-6488662

 

www.radware.com<= /a>

 

3D"Blog"    3D"youtube"

Confidentiality note: T= his message, and any attachments to it, contains privileged/confidential in= formation of RADWARE Ltd./RADWARE Inc. and may not be disclosed, used, copied, or transmitted in any form or by any means wit= hout prior written permission from RADWARE. If you are not the intended rec= ipient, delete the message and any attachments from your system without rea= ding or copying it, and kindly notify the sender by e-mail. Thank you.

P Please consider your environmental responsibility before printing this e= -mail

 

--_000_DB9PR01MB9980511CA0952BD4DF089316CC869DB9PR01MB9980eurp_--