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 A2B4DA0032; Tue, 12 Jul 2022 15:14:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8325841109; Tue, 12 Jul 2022 15:14:13 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 0BB80400D4 for ; Tue, 12 Jul 2022 15:14:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657631652; x=1689167652; h=message-id:date:subject:to:references:from:in-reply-to: content-transfer-encoding:mime-version; bh=orxs0ow1v6obLydZX/dpP0z6lbA4FgqgbK3aQWL5ib0=; b=kgNe9y2PniluZ4sh3q4un0vnuLsoxQW8Gh7i9v7irF5TgyWj30GOSRz2 /r2rR/bwdtoSoLHW0LO4edGBPmpwCsvnyKKznvb8FwziQkNNNL+yvgnRh Vb9hGwrgqEKvlVTE6gVrXJSpav++mw4xkhWBGyr4pRCVREwJBHRpoggFt FeC0K7vThGm17ZCTj9K7IB63TulcCkD8bah4HX5JklykGPqEp3nu8DdwS EmXNQQ4t0MmMLskqo+ldO7drFN4nF6jlhnfzRe27WQTxhVDbU8M8aRigb Dosz+ZTmj8pfCePxeEXiw7m5nZoJQ/GVRP3KmuuZOBuVMr6xwsFqdUMCj w==; X-IronPort-AV: E=McAfee;i="6400,9594,10405"; a="285670802" X-IronPort-AV: E=Sophos;i="5.92,265,1650956400"; d="scan'208";a="285670802" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 06:14:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,265,1650956400"; d="scan'208";a="570186418" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga006.jf.intel.com with ESMTP; 12 Jul 2022 06:13:50 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 12 Jul 2022 06:13:41 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Tue, 12 Jul 2022 06:13:41 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Tue, 12 Jul 2022 06:13:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NSX7j/WRnl839SiKGZYJcSxMdqfkIr8kgGK6ouqHROPdv8ko7jZKsGTzmBVdQZ9FnQhAZe32mosKjMWz0wfsKvK4frkgaouOwE3pHIdeS9k0UFnE854pd2uJjmkwk9yANfNA1uA8nrsY5LbNNb455lQxPAeCx/Y3TtQaReilKq+WCZMGHkltHW8v3W9Nayth2gxUMwHSye2PtMa/f2B7TEgGhVaQ6W9iGF0M6I0Sil6Ri7WcfzgFchzeyOzLzrQ5MT/Ew9m2m3tF3xYKheOVl8oXSdKAWyV+ljHPj55SQ2QqiItgTl8hMaybAYYBG3QoAIYaoRkOnQYLA1V8/f1GKA== 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=ppqcCJoJ+c/Dm33nONoUtoBIlh7Ck/G21W+MN1srSKw=; b=a7KxHt0WOHr09JZ45xYu0lUPBsJsiwahDYpl7mZ0evXZMIa4wDRRJ956Zh8G3Yoca9fZTyngO+zxxACJAh3Esg28LR01z0AcLN5ez38Z+qK/bS88VuAVaOy3y//eOdazE1/1BWkWFcvF31Spy+DWvSl9GZMVfEJsCVyyZcvMl8UKTmpLzxFfQxu1IBfTO9wah2QPWFFVDwhVAno7ojPDLHTjG5FWEpyUVVcZZF1mmkNi4hz/wnAXjguEk3oCzW4ETPbfsDvlgUJyp9T4nwEMFYEAzJ6ScRR91xpwVDUyZXX4qvh1ya4hLAK0XTJ39jnf5XeK5UQdYZmpaVnvRcY40A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from BN6PR11MB1251.namprd11.prod.outlook.com (2603:10b6:404:48::10) by MWHPR1101MB2079.namprd11.prod.outlook.com (2603:10b6:301:50::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Tue, 12 Jul 2022 13:13:39 +0000 Received: from BN6PR11MB1251.namprd11.prod.outlook.com ([fe80::128:8fb:9d0:1a9f]) by BN6PR11MB1251.namprd11.prod.outlook.com ([fe80::128:8fb:9d0:1a9f%8]) with mapi id 15.20.5417.026; Tue, 12 Jul 2022 13:13:38 +0000 Message-ID: Date: Tue, 12 Jul 2022 14:13:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.10.0 Subject: Re: DPDK 19.11.3 with multi processes and external physical memory: unable to receive traffic in the secondary processes Content-Language: en-US To: Asaf Sinai , "dev@dpdk.org" References: From: "Burakov, Anatoly" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PAZP264CA0093.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fb::10) To BN6PR11MB1251.namprd11.prod.outlook.com (2603:10b6:404:48::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99e34a38-86bf-4b5f-f9c4-08da640855aa X-MS-TrafficTypeDiagnostic: MWHPR1101MB2079:EE_ X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9ftIm/4RZQODIk8sgfIyBJzyiNG8x7//jNWtNl0wCZlfsgzqu6qbL3Z0LYXAyR9p1dSa4MwUAbAXn0AWFfuMoEomyjhyyruaeJVgAdTrVlRDS4ixi57LIRwqfuS+AtszBlrcUm5bTuKKEZR1ttpAJqhMKVwveB5oYaORkczNv4MzoliV4BqdN1IP4JZEZkBse/GxsrIlLpM31w1PfRIG7lb6UG0sl/9nGtbRfG3ZPw7Kj13XGAJ7/cE7bX3i67NEX3ggNgIKjIG2OJ2tAJT6t5QlsC6mtUUGlXnE7yFWGL2agcbpe1IJ8o//mht/idRjtlbGwc5Aq7rFZpdGoJH3IEU9UfGxUJ6FNSE7m4oLjA/NbY7d9qOATYrYJuvbcIDhriW+rIKA98X5KoaryLDtTeY2m6Jk7QcCawUcBqNmIK5U+nRSsC9cSNk4HEi35oLkNab/qChdB7FQCm76mwYfT7MJ3CQeWnLzWIxFLIs5Vkad1rWw2G8VprheTnlrxMtkUf5nJG+Ec+zmBTkabF8N1VLbFh7tNfaZzr87iHRFJJQAHaXOZ6ZZ/HW8HGYYuidmrdOHEQ4Q1JsH+ug/NayNEZYHOCaN0v6UoXhAH/6tkF8gNRAI9dBaOeJbCO4P7EK2foEk3J6m4X2fDejNx8Sz6YtBBPElOMs8wfALHzMOM45QHDPhu1pzFadhycuvaNLFJbGgI9ZXp5jLvui2pObh45Yd8/3ul8LTHFmhoYSKXhqABsUw/88K5hcE0VuWjddjgV1UnCACfz8Y1iexLqn0w1vR9ppC5YBsMDIFI5oI+YpWA33Ri1FryhtOCuv3OL8wPw4Pib2HYijaKeYyj2feW3S7MRmUo1bxp5ziDEwIlUrsuaxtPWyzWn1g7ABNpKjkpDn/JvCsp1ynPXt3vpHGI3NtDNV7Cnry5qMHyD0pwJc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1251.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(366004)(396003)(346002)(376002)(136003)(39860400002)(6512007)(41300700001)(478600001)(53546011)(6666004)(2906002)(86362001)(6486002)(6506007)(966005)(5660300002)(66946007)(8936002)(31696002)(2616005)(26005)(316002)(83380400001)(38100700002)(66556008)(36756003)(31686004)(82960400001)(110136005)(186003)(66476007)(8676002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RWxpRWV1UDRaZ091VWlhT2tQRmR3eWZrVjE1K0kzRUFqcTc5QVVEVGo4YmZj?= =?utf-8?B?YW93UzN5Z0ZFOFE0MU9CejQ4dVg0MUF0UEFxTDFaRGVUM1owNm9UWTMzUTh0?= =?utf-8?B?K0d6d3NjNDVaaTgxcUREVkpLVkViOTA0TkVGdlV3b1pPOGh0R3pvODJRR2I1?= =?utf-8?B?b051YnFjYjNEVDB0RW5scHVVWUhQM2RiS1BVVkZaUVpOallCcHUvVzN5aG9L?= =?utf-8?B?VkhVY0RLZ1E3VTZuZHFBM0o0SGM4cGxRY3NpV055M1lKcWhEWTA1aHROZ1hD?= =?utf-8?B?ZzR1d3Jkd044ZHI1L2JJOC94RFd0K1JLTmVPTk9IbWpadkhTMlVEVjB4aUhi?= =?utf-8?B?b0F4ZmNhV2YvUE11dm90Q01vWnpnUlhFcjhadEwydzNEdktYdzQwdi9la01D?= =?utf-8?B?bUZiTktQTUV0KzhObndUTlRIaFFuRHZwL2hRSTdlRmVQdUNuWEgzNVZEOGh3?= =?utf-8?B?bm1zMWU3b2VLRFpnb3BqcmszQjNiK1JTMEFVYllsMkdTNDFQWjNSWXM4SnB5?= =?utf-8?B?NGUrMDlnRTFFZDZYOStPK0NTZnJ3SllDdHI1eEFhT0tYYnFtVis5QTRpK2JX?= =?utf-8?B?S3l5bThvd0pwaDhoUGlReHRiNGN3SjJjZzI4RFNlOUdMQno5NEQ5eklxS0Zx?= =?utf-8?B?WWtGZ1JicE13R09LWDB3WGpnZFVyY2tYZGZQRTM2OFE4bXo4cXJid1dwbmx0?= =?utf-8?B?akdYaHBqUDdYUkZQczZhSkttdVhkUTB3Y25yUWtLc01CWFdiclRaUi9TZE9x?= =?utf-8?B?NTI5amVrVjFqZlNCbFh2dWs3KzZaN0VOMjNicVA2Z09HQWRDYTdxTWNmNHc4?= =?utf-8?B?b2cycm1hL3k3Y3dXVWpyekhDSFd0VE1USzVpbTd5L0pRVmtBcGFYeTdCSmVs?= =?utf-8?B?ZWErdXRWa2VqUEZJbEZjdWFST2dlV04vaWhXcU15UWx5WUdhWGZRNzJQeHNU?= =?utf-8?B?Tkk4OGxrYWJ4WVRxRytKQnZoMzA2cmhuRmhVUWFSNkc0STBCZXIxbll0MGll?= =?utf-8?B?LzFxcnJ5UGJ2Vk1OV3RxMFpnVEpaQnFDNTlqQjZ4b292REhvL1JOUkpibHVK?= =?utf-8?B?dXhqRjhSOHdIeDQ0bUxvcDU1eisyRWV1a0ZLaERMckxmWmF6VjVjR01GRW4y?= =?utf-8?B?VzNka2Q2cEZTNlQ3dHU3QjliT2lrSkhLNTNKcHlYTEJHNFlmT1pRWHFMSlkz?= =?utf-8?B?amNJcE91QVYwc25xcnNpcXpHcEdEeEFWR05idThGdXR0cFV4L3VhNE9sSlRL?= =?utf-8?B?TlJWT3JDYldOVTlCQ3NoT1VQN3VlNlNERkRVY3VjUXRyT3R5ck03U3pqckVD?= =?utf-8?B?a3BaWHRramFqVFhIeEVtMUFvTHdTUy8wUzFCVlZ3TnUrcGNqMStRUVJqNjNp?= =?utf-8?B?Y0xvR0FHM2xHQzVOM3hNRmxEQlZWUmFjYkpwaGtDczJGYjZ6Y2Y2MFR1UXJ0?= =?utf-8?B?ZThQTXZyS0tkN3RFRnJRL2U4WmRsMHVXbWdTMERiNENYL09vamlTL1ZiNW00?= =?utf-8?B?OWtwS216a3p3M05xVmg2Z0RINk1PL0NSRE11L1hzV0RyaUVudkt1MERCZmFw?= =?utf-8?B?c3ZNbVU3TGlVRzg2VDIxRytJcU9HeTgwK0duVkl6N1ExUkM0dFhqb1U0WVZz?= =?utf-8?B?RHlSN212Um9YeGRpYWFNVFB1UHZtZDluaUVMVVJ3eUd0TllhRmZUd2kyTTRX?= =?utf-8?B?SUZqME9IUVM0VnR4UUVJbmFKR0RKdXV6bEhkWm5qZE9IbWM5Tnp6LzkwZUdU?= =?utf-8?B?WlhMK2FNNGs2WC95dVZvKzdKNm9WM294bmkvcEh4SWhpQVVOSEJ0aWFPK0NH?= =?utf-8?B?Mmg1a2g3UHNsdFFsK2I4Sm1temJ1U09BSmZhN1ZTb2syUDJ0OUJleS9UdFZY?= =?utf-8?B?UDl4MXE1T0p5a1grNGRSeTF5VjhkVC9vbHpRVjlUdHhBSS9GTGhlN2JNOS93?= =?utf-8?B?MUYycktONGQ1QlY5cFJwdEN4eWVWdjRNSDJRUklwTElnbE85N1pGS3BEREhE?= =?utf-8?B?YlRHY2dESFRTYXVHN3U4ekNUdE9oM1hYbTJuWW1vbVR0NGNYVm1jK0FBdVZp?= =?utf-8?B?NHpsc0FlVENKZS9UTFo5S3hlSWVoVzRsWjZFZ3gzUkUwOCt5S2VpRE5MZHVP?= =?utf-8?B?Q2lLMnB5VENVSVdvTmNQejkyTXdMUW1ESjI2T1h4T0o3MWF6MmhPbSt2aXlq?= =?utf-8?B?L3c9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 99e34a38-86bf-4b5f-f9c4-08da640855aa X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1251.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2022 13:13:38.8474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: w8qgBDh4eiErwTVcuAnedbYuAQisBGb1ca8fJ/fA97X8qWVelYRi/NwJ5x1iIh8B3px/lRwlCu+CJXlQX7VRqr6UjLVAy0y7csA8rcsh6DQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2079 X-OriginatorOrg: intel.com 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 Hi Asaf, On 12-Jul-22 7:05 AM, Asaf Sinai wrote: > 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=ttyS0,19200 isolcpus=1-127 smp_affinity=1 root=/dev/ram0 > rwmode=r net.ifnames=0 biosdevname=0 systemd.show_status=0/ > > /memmap=0x1000000!0x60000000 *memmap=0x90000000!0x800000000 > memmap=0x90000000!0x1800000000*quiet cloud-init=disabled/ > > * We make all DPDK initializations in the primary process, including > mapping the mentioned memory regions via “/dev/mem”. > > After these memory mapping, we register the external memory, as > described in > 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 = open("/dev/mem", O_RDWR);/ > > /extMemInfo[i].pageSize   = pPagesInfo->maxPageSize;/ > > /extMemInfo[i].memRegSize = 0x0000000080000000;/ > > /extMemInfo[i].memRegAddr = mmap(NULL, extMemInfo[i].memRegSize, > PROT_READ | PROT_WRITE,/ > > /                             MAP_SHARED, memFd, memRegPhysAddr[i]);/ > > // > > //* Create heap *// > > /sprintf(extMemInfo[i].heapName, "extMemHeapSocket_%u", i);/ > > /rv = rte_malloc_heap_create(extMemInfo[i].heapName);/ > > // > > //* Save heap socket ID *// > > /rv = rte_malloc_heap_get_socket(extMemInfo[i].heapName);/ > > /extMemInfo[i].socketId = rv;/ > > // > > //* Add memory region to heap *// > > /rv = rte_malloc_heap_memory_add(extMemInfo[i].heapName, > extMemInfo[i].memRegAddr,/ > > /                                extMemInfo[i].memRegSize, NULL, 0, > extMemInfo[i].pageSize);/ > > /.../ Please correct me if I'm wrong, but it seems like you're specifying NULL as IOVA table, so that means external memory will not get IOVA addresses set. You need to find (probably using rte_mem_virt2phys() function) the individual page addresses, put them into an array, and pass it as an argument to add_memory call. See documentation[1], particularly the iova_addrs[] parameter. [1] http://doc.dpdk.org/api/rte__malloc_8h.html#af6360dea35bdf162feeb2b62cf149fd3 > > //* Allocate memory pool *// > > /memPool = rte_mempool_create(poolName, nbufs, DPDK_MBUF_SIZE, > poolCacheSize,/ > > /                             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 != > 0x7ffff4627000) not respected!/* > > /EAL:    This may cause issues with mapping memory into secondary processes/ > > */EAL: WARNING! Base virtual address hint (0x210100b000 != > 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: Yes, because you did not specify them as part of rte_malloc_heap_add_memory() call :) > > /[Jul 12 12:02:17] [1875] extMemConfig: heapName=extMemHeapSocket_0, > socketId=256, memRegAddr=0x7fff58000000, memRegSize=2415919104, > pageSize=2097152/ > > /[Jul 12 12:02:18] [1875] memZone: name=MP_ndPool_0, socket_id=256, > vaddr=0x7fffe7e7bec0-0x7fffe7ffffc0, > *paddr=0xffffffffffffffff-0x1840ff*, len=1589504, hugepage_sz=2MB/ > > * In the next step, we spawn the secondary processes from the primary > one, using fork(). > > This way, all DPDK data and memory mappings are the same on all > processes. For example: This is a recipe for disaster, because DPDK creates internal data structures that are mapped as files, and primary process expects to be the sole owner and user of those data structures. If you would like to create a secondary process using fork() at all, you should fork() first, and then call rte_eal_init() in the secondary process. A forked primary process is not what we mean when we say "secondary process". In addition, see documentation[1] for `rte_malloc_heap_memory_add()` - there's a note there that states: Before accessing this memory in other processes, it needs to be attached in each of those processes by calling rte_malloc_heap_memory_attach in each other process. So, not only you need to call secondary process EAL init, you will also have to call `rte_malloc_heap_memory_attach()` before you can use your shared external memory in your secondary process. Hope this is helpful! > > _Mapping in primary process:_ > > /cat /proc/1875/maps/ > > /.../ > > */7ffec8000000-7fff58000000 rw-s 1800000000 00:06 > 5                        /dev/mem/* > > */7fff58000000-7fffe8000000 rw-s 800000000 00:06 > 5                         /dev/mem/* > > /.../ > > _Mapping in secondary process:_ > > /cat /proc/2676/maps/ > > /.../ > > */7ffec8000000-7fff58000000 rw-s 1800000000 00:06 > 5                        /dev/mem/* > > */7fff58000000-7fffe8000000 rw-s 800000000 00:06 > 5                         /dev/mem/* > > /.../ > > * Unfortunately, when traffic is received by the secondary processes, > we 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 > memory on secondary processes. > > DPDK test applications show usage of anonymous private memory on the > primary process only. > > What are we missing? > > Can you please advise? > > Thanks, > > Asaf > > Radware > -- Thanks, Anatoly