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 C503AA00C4 for ; Fri, 28 Oct 2022 17:26:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CA6D40151; Fri, 28 Oct 2022 17:26:51 +0200 (CEST) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 07BF340146 for ; Fri, 28 Oct 2022 17:26:50 +0200 (CEST) Received: by mail-pj1-f45.google.com with SMTP id j7so1330367pjn.5 for ; Fri, 28 Oct 2022 08:26:49 -0700 (PDT) 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=wPc77nZLSATngT45UvLFfqsrk6mJEe+L2tjk3NdaV+0=; b=URhxkyEy1yIZluMDB/XRt17aXicMpMvs/INDt1ljpXKqD6CkfGg9288tljFyEo0ScR gqSCmpSJLNYOn/y4FkQE8VDOaC6tS95geTF31KrHs8cU+69aVqrLtP+LQ35w1FiuzLFT PggBudNBOIAJpXRvQ2gmQawlJnZoNT+3ptZN1bixm9axhzgSKzBHl7I+YU6CRJT/o/k7 0MitK6N2VWR7CEYiV0mAqrp6zshW60PfjtQIbUMoPaAwK1dZ99TXhMLD0tmmFOLxUUro cs4EBU8Nfb5nAcQDrQ7N13/3MLd3lhUwOel8yvHO3CgoKAGXLdzZfId+jc16ZQoFsM3P ptKQ== 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=wPc77nZLSATngT45UvLFfqsrk6mJEe+L2tjk3NdaV+0=; b=xpc/S8iGs+j0Kn7to3K+mT8t7S5Dj5umdoDYyLrKOY1VRL5G0PTLAWOB25nCCPbfty MZbbnH6OhKrqk44tbr31Gp6EEct0wYYmRpQ7TId7PdADXrJr/9udlryq2TNSqIDXzuV2 1gjiVnkuFjuMKgSHApl0ul6Q3ARB5ONHJ3SkD1vHzqpv3tb6wSTqQ0mh9GsPTlbiA80l grLuy4KHEg4QzF8svzkACITMvdikLRyWMeqR+v93lvZPSa9mMtRYIM0UFLb9BwsgZM80 +zgc+iEchIrdNwJvokMPjIhv9gXQTy2ZzYFNmvbcavcykSXs7vKbAvun07xJpJVluxbh sr8Q== X-Gm-Message-State: ACrzQf11jCLDTwbaT0TNZ79G2ayWn0tCiDy84n/VwWIcW/Dy8tPrVhkM CfaPRQDIXNHbkQEzUGqEBW/NOQ== X-Google-Smtp-Source: AMsMyM58ChJRZbrrV7ic1N19/BZF12cD8ok4J4mlBt2q/8qBqee/D584Ef2Uxam6wbX4RMJxqsh6TQ== X-Received: by 2002:a17:90a:5e04:b0:20b:1f20:5069 with SMTP id w4-20020a17090a5e0400b0020b1f205069mr16623577pjf.126.1666970809131; Fri, 28 Oct 2022 08:26:49 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id i3-20020a170902cf0300b00186b6a04636sm3158382plg.255.2022.10.28.08.26.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 08:26:48 -0700 (PDT) Date: Fri, 28 Oct 2022 08:26:47 -0700 From: Stephen Hemminger To: Gokilavani A Cc: users@dpdk.org Subject: Re: rte_pktmbuf_alloc( ) returns same mbuf address which is not freed Message-ID: <20221028082647.1305b07c@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Tue, 25 Oct 2022 14:11:26 +0530 Gokilavani A wrote: > Hi, > > We have been blocked by this issue. > > Can anyone help us to resolve the issue? > > Thanks > Gokilavani A > > On Thu, Oct 13, 2022 at 4:39 PM Gokilavani A > wrote: > > > Hi, > > > > > > > > We are using *DPDK-19.11.11* for our application in which 4 construction > > threads construct packets periodically, place it in a circular queue and > > > > a transmission thread pushes that packet by reading that circular queue. > > > > > > In the long run, We are facing a crash in *eth_igb_xmit_pkts() *call > > which is called during transmission. > > > > > > After an inspect with GDB, we came to know that the non-freed mbuf address > > is returned by* rte_pktmbuf_alloc() *for another packet during > > construction, even though that mbuf is still not transmitted by the > > transmission thread, which makes the corresponding construction thread to > > update the same memory again. > > > > > > It is not clear why rte_pktmbuf_alloc() returns the mbuf pointer before > > that pointer is not getting freed by rte_eth_tx_burst() call?. > > Off list discussion. This application was using m->next for private data. Stop, this is not expected to work.