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 B7F0C4293E; Fri, 14 Apr 2023 11:08:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A9B7140144; Fri, 14 Apr 2023 11:08:18 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id A8B33400D5 for ; Fri, 14 Apr 2023 11:08:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681463296; x=1712999296; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=G98vJMTycIAUaFyKRNdpgKv925FPm3CblW+3D+hlPOQ=; b=PVY8InXJ6YCACczuKfDqzejclYBpais6kgaZEn8QQTufX2o1NTM7k6Ov MmWexmR/enqxLktlLgE3m7iYffEpdd9EOSzpfDSGovadMGEANO+vpeetF lYjXhW+BfEwclBibutuQfW+jAmkT3wmVbu0JQZ+kkEYsi9NLnyr35OfMK 3oUSiG+b+OXje+jzm6kjDGZMDqiHiQBjyOpc1abNpBlcVnEQOB5Bijy6L QbthTFnpIvNdryHWK+NnDUFIlgfm0yt8ylYi0ovT9ZsbUrahqqH25jS4H E09yQ+k07Q31eUxldBjY4t9M+YGB/dwxLvdSzecurMEKdxVdD9bLvIDQJ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10679"; a="324050072" X-IronPort-AV: E=Sophos;i="5.99,195,1677571200"; d="scan'208";a="324050072" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2023 02:07:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10679"; a="692332342" X-IronPort-AV: E=Sophos;i="5.99,195,1677571200"; d="scan'208";a="692332342" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga007.fm.intel.com with ESMTP; 14 Apr 2023 02:07:59 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 14 Apr 2023 02:07:59 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Fri, 14 Apr 2023 02:07:59 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Fri, 14 Apr 2023 02:07:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LOxnAO/iDSFzoZiex/LQDbYDlhGn0+TResIMlWoxQRj1Yvy1FayXJdzeZcNptUn4ug8QarsFcfOrP0r1yG161rEbTPJ9IZfi1y7A3Bg7VOfQcKyHpTPohfGY47R/UrMXA2TjxXuHgzAngzK6yb8UCxkKjMr29BXAN4swsrsymwuSOSqX91pBbb3CImUo3WpDQit0k6x1Jok7PjredCUw4Um6Pq0V5pgPV3OnhQ+TMTW5OQyz/JNSfYrxpwpHtgqx392j6OeTqx4BySbr5DlWANmmQ2skUrn28AMlIth4bmQ8FypXpjVAOEVcFnhlYbKKLiiXpmpHK8bbhgcR2nA0QQ== 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=HRAemf8RYswY4rRzrXOpIN2MCtlYYaB7KFoeR0Bu3bQ=; b=Je1c2z1+dwWsz5EaR74YnbJs3LdqEvI3HrSPUSh2Q+RTBT37esCnhnp+2yLmewC3/4ZzdgPJ2ryLp8A7ZJnhAb4Cie+1uXfzgMGMFpiMUoxikORPpumzoo0PQWBwlfPz5V4pNyKYO81NPUF3rP0M1nhgzHR8cOEPZULvYMxfdMBPHgNOAsZIwP3jV3paCciPkLgX0yEOcBc15TLNNabXRpkobw5WWlulOx4wTvAvc6HsnhmrlH6ZVR+MB6LWAG1Epm/Ei8aOQTPNZMYJHdzZtTuIlY+IAWrEwRsgRasoc1MOZKLUDm9jSm9GYlsbhfqe8x5uPU38GVZJulDFx7JMrg== 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 DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by SJ0PR11MB4942.namprd11.prod.outlook.com (2603:10b6:a03:2ac::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Fri, 14 Apr 2023 09:07:57 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::695b:260c:f397:2b69]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::695b:260c:f397:2b69%4]) with mapi id 15.20.6298.030; Fri, 14 Apr 2023 09:07:57 +0000 Date: Fri, 14 Apr 2023 10:07:51 +0100 From: Bruce Richardson To: Prashant Upadhyaya CC: Subject: Re: Regarding DPDK API's like rte_timer_subsystem_init/rte_hash_create etc. in VPP Message-ID: References: Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: LO4P302CA0040.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:317::15) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|SJ0PR11MB4942:EE_ X-MS-Office365-Filtering-Correlation-Id: bced3f00-ff24-4f54-beaa-08db3cc7bcee X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NnMn+dYinaxrmpov7c653nvYTs+p9tfhkPySxw+0H9yzvKnSquJzUgC1nBSL5I01LNL4SryWCy9quEmZWqSt2I6iEmiB+JJ+Ztgr5aihMnyjTdbLSdRkpNgn5SGX/hFoNJrWvZESOUUE3rvIu45rNbrDRuB6owD91vhEQjNxV199zhrtqOyi2BzfKtHi9kLtPNLQEAk5KkIzc9opFJhncCXnj+jcbgsZJXsHc85gyUJ3PKLrAAmNDR3EQqy0EC4Z8e9vWAg21LhrBNKJJEBayLtbWI7sv0yoeRvxgDB3zUGfBIZnA2zup/MUifKmlbsPt5uYioMGvnLljouOJLkg5E2gMaVL6VJBYhO79zyTO7UMC//DRBgDN8kVxgPmjBtcDUIjCCCDGehd6Ctka5tk3ZlQD7TgoAYZ5tnsJawOGgPkSXXwXz7WhumMle7XTvNYLmNhdAthHZqfLImLxNMtwtA7w9RZ+P4ZBYO3Pz9XmBrTUMFtmv/1eY256GaEXbXhjqG8XnAIJCmF0sN6z8ngNwk6+DlQlrzDuRrw+KzLCSZCc2xtFxFYwIhPASIKNC9L X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(396003)(366004)(136003)(346002)(39860400002)(376002)(451199021)(316002)(4326008)(38100700002)(6916009)(82960400001)(66556008)(66946007)(66476007)(44832011)(5660300002)(41300700001)(6666004)(86362001)(6486002)(6512007)(26005)(186003)(53546011)(6506007)(2906002)(83380400001)(8676002)(8936002)(478600001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vlo1S2M2M0lVNzI0UVEwcHc5cHU3ZU9WM2xDODhOaVF0cmxsaFBvZWhEazJZ?= =?utf-8?B?RVhUZVRuai80TzlPa3Y0WnVQRFluVjZack9USlBzWnU1Q0lFcXlLeDUvZzM3?= =?utf-8?B?bllHYmorR1pNeEVQQk00SUVXMFpIajAzSElVZllQcXN6WEpNc1RESTNFdnE1?= =?utf-8?B?VlBHM1JmVEJxdXRBQUM5UTk2TVhFSUc1OHRIakQ4N1FvWG1QSElPeTZUeEdY?= =?utf-8?B?M0tLenRDUm5ZMGNYNjhxWjRXMERWSk9SaGcyTiszZ1M5cUZEOGZTY3hYeGlH?= =?utf-8?B?bncwZGhXd1cxVUVzbSswY3hZYUZNaXJudEUrNXM3VU15ZHFvRXRRb2g1eXhU?= =?utf-8?B?aG9NZXpkSTdYTlhOSXozdVJPSElrNlAyU2RoU0V2TnhGaDRpdHVtZ05ndnZq?= =?utf-8?B?SGx2bEl1VTNUZHdZL3kwUklxeFlNNGVUcVllVmN1dlArSUFsSk12dkdpOGtP?= =?utf-8?B?Y0loaHhpUHp3MDdSdDRkc0hUZlY0L2xTVng4UHFsc0k0V1k1V2VrUXlvdFZu?= =?utf-8?B?eDJDNnhMa0lkL0FaRGZwdHJvUk5uOUhGL3pLeGVCcndySzhmVzJmNUIySnZB?= =?utf-8?B?UDMzcGVTaEMzQmhSWDhkRjcvS1RJalVZMzZUK1huVy9meTdXZW9OTVdGSmQv?= =?utf-8?B?M0N2RlJzcE5pUCtaMENXSTlMWmV0SGk2SXZrVG5lbTR2RlRiUWJZY3dOVGNx?= =?utf-8?B?ampHc0dDQzBwMlYzL1gwbnViTXRHUlhyakh3elJJdzVUU0d3ZTJoSE5jbnNz?= =?utf-8?B?cGV5OStsRzdVZUpvUkN2cmdiM3NiYnFIMkd6NmNNcVNmR2REU0pZaXFVQkps?= =?utf-8?B?WUREam9BTUwzcVhCNFVDcU5SNkRRZ1FlT1IxeHpuY09CMVpsZXZORzEzeWtz?= =?utf-8?B?OGtqN2hEZ1pWS1hLT2JTNU5ueDVPSWRKZUt1UTliWnowUitZaDNNWDZuTU8r?= =?utf-8?B?aGpCWDdBWFhIQUdsNFNZM2ZGUXhnLytqMTlNcmNMbFB2K3FiNUw2eHRRTTBw?= =?utf-8?B?c3VOSm04cWtPS1hYbkdVTjlkMjM5dW01WU8vNXY5dTJLVUo3RitUQ3p4b1Jl?= =?utf-8?B?QTJGZytEbmVZeVdCWFYxS1JCU3FEMzNVT2h2MmNSVVI4V0tpRDFuVmNKb21v?= =?utf-8?B?ckUvVERZQXpSWkpiYVhpOWhpRU96Q0UxSlNDd2VKNnRUTUl6QzRGQ0NOaFNo?= =?utf-8?B?SWFwL1FraFlWdCtCRGFtY3FWZkRmTElVVkMwbXlJR3AwVSs1ZnZ0Z09sLysr?= =?utf-8?B?TlpMUzRaYUY3eVlXbEpzVS9WcjNzRWpDUnR5ZTVZd01pNUdjUXgxTzVwSmYw?= =?utf-8?B?bk1Oa0NTaU4xNTBRcHZKUUxKTE9aeFQ1cHZINmNGSy9nUlhXbTZaejgza2dj?= =?utf-8?B?b2JiMmFKMDRtcEdZQ3FQcFJIS2hPQ2ExeDluUjI1TEdTWXhqWVZPTm92Q2ox?= =?utf-8?B?WW9td0RRSWVqLy9WYVIzZ1VLZFFkR3VwenNuVTlUVUN0RWQyNlJkM1JVZmFO?= =?utf-8?B?SlVZWlhDT1lqa1loVmoxbHN4NmxSOERPRXVNaHNMVSswb2U1bUNlYUgxVFc3?= =?utf-8?B?ZG42Y2JQVGtMaVczODdYdmh2NFRHS0xkTzNNdVd2THNuK1UxK3BQTGdKaHl4?= =?utf-8?B?UHUralAxTlNTSC8zdWFDNzRCWWY5aExoSVNpT29oZ1VIVlZmVml6VDNuR2Zr?= =?utf-8?B?bkZzMFhqbzZoYXl0YnZOeSt2YWpHZ3FyQVk4WTlLdlN3NEdqOUg1RFZaVHhk?= =?utf-8?B?WWplUDc1TjY4cVNQTFQ2Nmp2WmlWMnZqeHFwcHpPQlRNNkVKdDlGNkZOazNz?= =?utf-8?B?bzlYR0hCLyswcXAvd0dpMGJHSXh0OFlQa3d0RVk4RUxJUDJaSEhwS2x3RHJM?= =?utf-8?B?S2hvU3ZvTEF6a0g4UzljMUM0M2R5MlZjdncvbFpvVk9BVTVyUmlsNG9KYVlG?= =?utf-8?B?U05LZXVjVlI5SFNmTUtUQXpZNXdzUVRNOC9GNXo2NEhtZWdOTDgzY2p5aStN?= =?utf-8?B?clppVFF3VjlmTUEvdTJoazV2YWhsdkVKWDI5VkJYREs4Tm1sTDR0Umd1ZlFB?= =?utf-8?B?c0luNjVGc21XSDllQ1ZPSXN0ZnpqcC9udUZiMVhGMWw2UXpwaUVVUXpqVVRX?= =?utf-8?B?YmFGNys4Ky9xL0lEVGV2Y0FTU3lwUzVHMjBEUlNHSDBzNDJDRzhnRmJFbWpH?= =?utf-8?B?YWc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: bced3f00-ff24-4f54-beaa-08db3cc7bcee X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2023 09:07:57.1749 (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: DQEcyGc8O6iaIsC9oH4IVyOnwczijuuI7VkVFo0I4cHLWxzMoktP6+Dk4OYRXiD2OVNnnWLQJMcYVPOtULqegj5jGCVev7727RYrRakof+w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4942 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 On Fri, Apr 14, 2023 at 09:55:31AM +0530, Prashant Upadhyaya wrote: > On Fri, Mar 31, 2023 at 4:19 PM Bruce Richardson > wrote: > > > > On Fri, Mar 31, 2023 at 03:11:18PM +0530, Prashant Upadhyaya wrote: > > > On Thu, Mar 30, 2023 at 7:34 PM Bruce Richardson > > > wrote: > > > > > > > > On Thu, Mar 30, 2023 at 07:07:23PM +0530, Prashant Upadhyaya wrote: > > > > > On Thu, Mar 30, 2023 at 6:47 PM Bruce Richardson > > > > > wrote: > > > > > > > > > > > > On Thu, Mar 30, 2023 at 06:42:58PM +0530, Prashant Upadhyaya wrote: > > > > > > > On Thu, Mar 30, 2023 at 2:50 PM Bruce Richardson > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 01:57:52PM +0530, Prashant Upadhyaya wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > FYI, when replying on list, it's best not to top-post, but put your replies > > > > > > > > below the email snippet you are replying to. > > > > > > > > > > > > > > > > > The hash creation API throws the following error -- > > > > > > > > > RING: Cannot reserve memory for tailq > > > > > > > > > HASH: memory allocation failed > > > > > > > > > > > > > > > > > > The timer subsystem init api throws this error -- > > > > > > > > > EAL: memzone_reserve_aligned_thread_unsafe(): Number of requested > > > > > > > > > memzone segments exceeds RTE_MAX_MEMZONE > > > > > > > > > > > > > > > > > > > > > > > > > Can you try increasing RTE_MAX_MEMZONE. It' defined in DPDK's rte_config.h > > > > > > > > file, so edit that and then rebuild DPDK. [If you are using the built-in > > > > > > > > DPDK from VPP, you may need to do a patch for this, add it into the VPP > > > > > > > > patches direction and then do a VPP rebuild.] > > > > > > > > > > > > > > > > Let's see if we can get rid of at least one of the error messages. :-) > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > > > > > > > > > I did check the code and apparently the memzone and rte zmalloc > > > > > > > > > related api's are not being able to allocate memory. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > -Prashant > > > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 1:30 PM Bruce Richardson > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 10:30:24AM +0530, Prashant Upadhyaya wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > While trying to port some code to VPP (which uses DPDK as the backend > > > > > > > > > > > driver), I am running into a problem that calls to API's like > > > > > > > > > > > rte_timer_subsystem_init, rte_hash_create are failing while allocation > > > > > > > > > > > of memory. > > > > > > > > > > > > > > > > > > > > > > This is presumably because VPP inits the EAL with the following arguments -- > > > > > > > > > > > > > > > > > > > > > > -in-memory --no-telemetry --file-prefix vpp > > > > > > > > > > > > > > > > > > > > > > Is there is something that can be done eg. passing some more parms in > > > > > > > > > > > the EAL initialization which hopefully wouldn't break VPP but will > > > > > > > > > > > also be friendly to the RTE timer and hash functions too, that would > > > > > > > > > > > be great, so requesting some advice here. > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > can you provide some more details on what the errors are that you are > > > > > > > > > > receiving? Have you been able to dig a little deeper into what might be > > > > > > > > > > causing the memory failures? The above flags alone are unlikely to cause > > > > > > > > > > issues with hash or timer libraries, for example. > > > > > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > > > > > > Thanks Bruce, the error comes from the following function in > > > > > > > lib/eal/common/eal_common_memzone.c > > > > > > > memzone_reserve_aligned_thread_unsafe > > > > > > > > > > > > > > The condition which spits out the error is the following > > > > > > > if (arr->count >= arr->len) > > > > > > > So I printed both of the above values inside this function, and the > > > > > > > following output came > > > > > > > > > > > > > > vpp[14728]: dpdk: EAL init args: --in-memory --no-telemetry --file-prefix vpp > > > > > > > [New Thread 0x7fffa67b6700 (LWP 14732)] > > > > > > > count: 0 len: 2560 > > > > > > > count: 1 len: 2560 > > > > > > > count: 2 len: 2560 > > > > > > > [New Thread 0x7fffa5fb5700 (LWP 14733)] > > > > > > > [New Thread 0x7fffa5db4700 (LWP 14734)] > > > > > > > count: 3 len: 2560 > > > > > > > count: 4 len: 2560 > > > > > > > ### this is the place where I call rte_timer_subsystem_init from my > > > > > > > code, the above must be coming from any other code from VPP/EAL init, > > > > > > > the line below is surely because of my call to > > > > > > > rte_timer_subsystem_init > > > > > > > count: 0 len: 0 > > > > > > > > > > > > > > So as you can see that both values are coming to be zero -- is this > > > > > > > expected ? I thought the arr->len should have been non zero. > > > > > > > I must add that the thread which is calling the > > > > > > > rte_timer_subsystem_init is possibly different than the one which did > > > > > > > the eal init, do you think that might be a problem... > > > > > > > I am yet to increase the value of RTE_MAX_MEMZONE, but wanted to share > > > > > > > the above first for any suggestions. > > > > > > > > > > > > > Given the lengths you printed above, increasing the MAX_MEMZONE will not > > > > > > help things. Is the init call which is failing coming from a non-DPDK > > > > > > thread? > > > > > > > > > > Likely yes, at the moment I am calling it from a CLI which I have added in VPP. > > > > > Assuming this is the case, do you foresee a problem ? > > > > > > > > Could well be a possible cause, yes. With non-DPDK threads, the memory NUMA > > > > node/socket-id entries could be invalid, and cause the DPDK memory > > > > allocation to look for memory heaps on non-existent NUMA nodes. > > > > Can you try using rte_thread_register API in your thread before calling the > > > > init functions and see if that helps. > > > > > > > > /Bruce > > > > > > Still no luck ! > > > I tried two things -- > > > First, I tried to make the calls from the VPP's fastpath thread (which > > > I hoped would be a true DPDK thread internally), but the calls failed > > > like before. > > > Second, I tried to do a rte_thread_register on this fastpath thread > > > before making the calls -- this did not help either, same problem. > > > It appears that VPP's memory management has done something so that > > > these rte calls are not able to access the expected datastructures at > > > DPDK level. > > > It appears I am the only guy in the world trying to make these rte > > > calls from VPP plugins, I checked on VPP mailing list too and the only > > > suggestion I got was to replace DPDK memzone/memory allocator > > > functions with those of VPP. This becomes intricate work as I call rte > > > timers, hash and rcu functions in my code. > > > Can I patch DPDK in a generic fashion to reserve memory from a VPP > > > allocator function or even a malloc at some centralized place or a set > > > of functions in DPDK ? > > > > If doing any such patching, the patches should add new init functions to > > DPDK to allow init with already-allocated memory, or with a custom memory > > allocator to allow reserving X amount of memory. That's the only way I can > > see to do a generic version here. > > > > > But the larger question is what are we running into here which is > > > causing these issues. > > > > > > > It's a very good question. I don't know enough about VPP to answer that - > > but I suggest you ask on the VPP mailing list, as its likely others in the > > VPP community may be better able to help. I would suggest doing this before > > looking into any patching of DPDK, there may be easier workarounds if we > > know the exact root cause of the issue. > > > > Regards, > > /Bruce > > Hi, > > I could finally get over this issue. > This would probably not be of interest to DPDK community but I am > putting up the root cause here for the record. > In VPP, there is a DPDK plugin (dpdk_plugin.so) which links with DPDK. > This does not export symbols because of the way VPP loads this shared > object. > If I link with DPDK in my own plugin, then it effectively creates a > second copy of DPDK which leads to the issues I was seeing. > As per advice from VPP community, there is a way in VPP to let the > DPDK plugin in VPP to link against the system installed DPDK libs, and > also let my own plugin link against the same system installed DPDK > libs. Then everything works as expected. > Thank you for sharing the solution with us. It could well be of help to others.