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 66AF442870; Thu, 30 Mar 2023 15:13:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ECC24410D3; Thu, 30 Mar 2023 15:13:11 +0200 (CEST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by mails.dpdk.org (Postfix) with ESMTP id A3C0240E25 for ; Thu, 30 Mar 2023 15:13:10 +0200 (CEST) Received: by mail-ed1-f54.google.com with SMTP id er13so35287399edb.9 for ; Thu, 30 Mar 2023 06:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680181990; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PoWMX3XCy1MdX7DgmxBBcveATGARRmdaAWgKSC4vQNU=; b=GoUTLrOMug3w40BEZqRS3gOeIj8b/sBAh/gatLcLP7hQttPDulbuesiAG8F0+tCryN qqHYO9J8QVZDlaASBPlxh1YjfldgI7SRvssahYRFIhUSJekjXB8x9mWF6sPod0eoWRvB TH2TXo7m5dKjf8ze6ofH2IAMORlZIfWVIQk5IkxJt8JeMP44w6JVcl08SzWfHbM2Rvw7 9I4ePXY2I8zurp/x4QqpjoTxXw2Cl+sbJkfUKDNderYpPeykObBIlGoE+FKipGfeldXq rNaltCfZ1Uy7WajUjVn7Z0TR9hqS9lShpv3uwXCoA6bEDfdFhtuIsX/G/grEgriYbvJM DR4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680181990; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PoWMX3XCy1MdX7DgmxBBcveATGARRmdaAWgKSC4vQNU=; b=DO4/FzHOC9N9mp3rYGA2gdKNimMac0mHS8sAJE+8Zg+W1OP7fcbA/Fb7icoO+pzE7I Vv3cvhDO+ZvLAXF8WSW1HG/CDUahAsXs7VTqX5hh7dn6R7JEBnMmhvbJF0Ni4gQR+Kqy xkrkP0Y3iMau9Zxqq42DHXaoFFJpPMrjzLPKd6i33o1rQuNAufbeC6W+2gyAqYxps8D6 l3P7a6je0EwLc1QB4DH7Yd0Jpcv+nTny2Wj9ZaLMMMQyNJsOOxpTyNSIrBH/GPlnjAMR SJaC9h+lzocFRnNUMzxYIwUxtnIVg5rMcjs+u5fchlG/3Q3mZhh0j12Hh+ukU6FvzTBO rbxg== X-Gm-Message-State: AAQBX9eeO7rvZJ5FMrufP3JdTdueB0oSgtvP6PbmY5lEQs1TP5dgbV0m YN1/pqW7N304OzTPaZ5TZWG5NPHFBQwyK+YER7eMkV/tWyNotA== X-Google-Smtp-Source: AKy350Y6mZdJ6Xc5rsToX61Q8Fx9VFKstEtkxHG6yEc246vDpKZeH9rL2aOnSq73ZmRL0yTfSaVN+308Mej/P0XqFC4= X-Received: by 2002:a50:998f:0:b0:4ad:738b:66ff with SMTP id m15-20020a50998f000000b004ad738b66ffmr3346129edb.2.1680181990118; Thu, 30 Mar 2023 06:13:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Prashant Upadhyaya Date: Thu, 30 Mar 2023 18:42:58 +0530 Message-ID: Subject: Re: Regarding DPDK API's like rte_timer_subsystem_init/rte_hash_create etc. in VPP To: Bruce Richardson Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Mar 30, 2023 at 2:50=E2=80=AFPM 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 repli= es > 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=E2=80=AFPM 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 backe= nd > > > > driver), I am running into a problem that calls to API's like > > > > rte_timer_subsystem_init, rte_hash_create are failing while allocat= ion > > > > of memory. > > > > > > > > This is presumably because VPP inits the EAL with the following arg= uments -- > > > > > > > > -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 woul= d > > > > 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 ca= use > > > 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 >=3D 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 v= pp [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. Regards -Prashant