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 6527041D53; Thu, 23 Feb 2023 19:01:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E936440C35; Thu, 23 Feb 2023 19:01:31 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 8A1C040693 for ; Thu, 23 Feb 2023 19:01:30 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id l1so3576360pjt.2 for ; Thu, 23 Feb 2023 10:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NdXhYOMT1FYxWewrN0ikHn932DsDDbsOswk1z1Evt5c=; b=JC5HIWRhg3EaInSebCMK96OFb7bVgBJLbu+UbPZwkyRzKzyaC1Z3oC1mAQy0NuiPS5 Kj1zFro7quyZcPEuDV111skFFQQbEPOxewimrtu9ZKIbEu/VX8S3n8u5FUElJH0nFAmW ne6Quvma03ZLd9IrkxrNFjbmpT9qL5lh9Vo8HFBICJxOHrxWVsj4DXBm6e0p9iF155gk 5ZUDM5MAKSDpFplk7eZ0LOc9eFdbc1jPV5NcEekrdN6PfmQr+GweYxpCdwh2jgYIVqLL ALjZtwbKygmACVGfUWTgQD2a/bgRTZktTvBkSmW3x6txsEyPG1XGshBYzV4EPAVurCLA 16Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NdXhYOMT1FYxWewrN0ikHn932DsDDbsOswk1z1Evt5c=; b=THR+s7p6eobWUdskExlTlPIc91Fkhqt8RlGeBYfOhUfhD/QBbakiRPid9W81ZeH+8r WiE/6G/hyvQ6Oe2TC+MoHoMFOYNT8WbYS6dSfAGrtviBxoO5hZNR9H8gveXfTTeQrrSL byXkh2tyEQVDKH0Hc86tdVQQU8YrDW/EUsr13TW1nh0tTu1HtprsV8hVd4yFLvALexGT iPGJlKkiV6/DqTMIFuqA48k//44kNvVSHxMR0lSFFhTUyqebi+IfVeC4blKvv7Fr7vZO QiM8kdZjJuK6w8HYz1Z8dJ+FxNBrB2axSEiY8mmG1oHn1Ru7xaBSMFYIPHMoTzSb0YWv daPw== X-Gm-Message-State: AO0yUKXJ0830sPHmj2PvEaOn+8hRthw85rZwNn3cHCXgKDLM3H7zOYBx yYtR5+CtOvGRT46rBFL4KKEctw== X-Google-Smtp-Source: AK7set88As7/Z6sIvtPD9qr1EODTlxFdjaPPsandehR6I/TUyAclArVxHp/sW3azSAsD8duFw0u98Q== X-Received: by 2002:a17:903:32ce:b0:19a:aa0e:2d67 with SMTP id i14-20020a17090332ce00b0019aaa0e2d67mr13679443plr.32.1677175289488; Thu, 23 Feb 2023 10:01:29 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id b2-20020a170902d30200b00196047fc25dsm1731134plc.42.2023.02.23.10.01.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 10:01:29 -0800 (PST) Date: Thu, 23 Feb 2023 10:01:26 -0800 From: Stephen Hemminger To: NAGENDRA BALAGANI Cc: "dev@dpdk.org" , Kapil Kumar Jain , Ramakamesh Duvvuri Subject: Re: rte_pktmbuf_alloc() is returning same address on two consecutive calls Message-ID: <20230223100126.6ad6d06b@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 23 Feb 2023 14:54:13 +0000 NAGENDRA BALAGANI wrote: > Hi Team, > > In my dpdk application, I am facing an issue where rte_pktmbuf_alloc() is returning same address for two consecutive calls in a single thread context. > > Following is the code snippet, > > int Func(struct rte_mbuf *mblk) > { > struct rte_mbuf *tmpbuf = nullptr;; > struct rte_mbuf *copybuf = nullptr; > char *nextPtr = NULL; > > tmpbuf = rte_pktmbuf_alloc(mbuf_pool); > > nextPtr = rte_pktmbuf_append(tmpbuf, IPV4_HDR_LEN); > //update some info on nextptr > > copybuf = rte_pktmbuf_copy(mblk, mbuf_pool, 0, pkt_len); > > .... > return 0; > } > > With the above snippet, 'tmpbuf' and 'copybuf' which are getting allocated from same pool (mbuf_pool), pointing to same address, Due to this tmpbuf which gets allocated first, and further populated, is getting over written inside rte_pktmbuf_copy() call which is not expected . > When I further debug , rte_pktmbuf_copy() is internally using rte_pktmbuf_alloc() to get the free buffer from mbuf_pool and copy the data from mblk. > > Please let us know if there is any known issue with rte_pktmbuf_alloc(), and why it may be giving same address on two consecutive calls. > > Regards, > Nagendra > Most likely your mbuf pool has gotten corrupted before you get to that code. Try building with the config options for POOL and MBUF debug.