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 57C3AA0543 for ; Tue, 25 Oct 2022 10:40:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4DE8740A89; Tue, 25 Oct 2022 10:40:48 +0200 (CEST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by mails.dpdk.org (Postfix) with ESMTP id 4F863400D5 for ; Tue, 25 Oct 2022 10:40:47 +0200 (CEST) Received: by mail-ej1-f52.google.com with SMTP id y14so10647357ejd.9 for ; Tue, 25 Oct 2022 01:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=L+ZXYQtF17dwpALNflyGE7/cVa/Q/n5zqDwf3EV5YPE=; b=dFdOR13ZzzfTtPot/gAx6ZVmV7cgm4LkMAKuhpDC6FPq1w2vudm3U2pLmcMqDzDWxd M/ZJIVf+KKGXDj8nu2j+1gccIWfemmNPlx1ktigqZO0/BMaAkXXJ5UwrLXgGpl2wEOV/ K7hwcWLg1QRnLgHasaQC9lKoJIeLjph/CCGlbo0Yq+Pf8B7gkHFSHUvBfpCgNUewdN5y rm8bqJAwUYuLaoDFNd0d9hWhfI8mPblhgBufcek5bS8y75zYWzYAoP+B9S8aXHkuHDxY 2MdE4yiSTDKqsYhvkdhX/Fh4wfODZuqhuUnnM6zx2TO0j8QIlFPGDlNOxvtYRe0/LMs2 IaUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=L+ZXYQtF17dwpALNflyGE7/cVa/Q/n5zqDwf3EV5YPE=; b=TJA7jPFInJgFIVpVmacSS4Jw7Ywa+letD0AQDbmuRnYychfUhsXINzknf8gCGvNcIX Ysm/Z8u47M4nLQ0myTJWboGAWg/+WnHBAPNzt4pwv89aFKVvBvmASPeHzIM/uBcxBB67 nTThGwD4nRCBbODHdrZNUEMFhQ3utFYVWi7WJKVtCNr5C4TItdFO6WArqsdXw26RxTpE 7XIfjz+KlJTSsPxktgT9n+LEXK3hSR7dMiVK80hmOEvxfTirq0LpHpTi4pwOPGupu86l Mup3EJXlts0VwcKzMefh05y/W6jZ5fnJwSCv0b05j4Z4UeVIF8nYbZ5ay5ljyX11Y+et 4OVQ== X-Gm-Message-State: ACrzQf0cmwrLjecRmf+g2DXzVE2wK6Kv8oQ+yiGTv9PnrsWzifOi8LH6 OmVYr55FzGkmE+85NNhExPB/Pool0IPtdBA+Gm/7WIAT X-Google-Smtp-Source: AMsMyM6DHsPZiALWRGfm0N/Q0Vm0UKlR/bX6p4UYgzGs4B5arvDZ3rOia5N1kKk5gdJeDQnbyHs++nXsKGrFayUqg5M= X-Received: by 2002:a17:907:1b12:b0:72f:9b44:f9e with SMTP id mp18-20020a1709071b1200b0072f9b440f9emr31123943ejc.653.1666687246499; Tue, 25 Oct 2022 01:40:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gokilavani A Date: Tue, 25 Oct 2022 14:11:26 +0530 Message-ID: Subject: Re: rte_pktmbuf_alloc( ) returns same mbuf address which is not freed To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000047853605ebd7dd51" 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 --00000000000047853605ebd7dd51 Content-Type: text/plain; charset="UTF-8" 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?. > > > We have created the mempool using the call, > > *rte_pktmbuf_pool_create(txMemPoolName, > 16384,RTE_MEMPOOL_CACHE_MAX_SIZE,0, 2048 > +RTE_PKTMBUF_HEADROOM, rte_eth_dev_socket_id(0));* > > > Please guide us in resolving this issue. > > > > Thanks, > > Gokilavani A > > > --00000000000047853605ebd7dd51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have been blocked by = this issue.

Can anyone help us to resolve the issu= e?

Thanks
Gokilavani A

On Thu, Oct 13, 20= 22 at 4:39 PM Gokilavani A <gokilavanianbazhagan@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

We are using=C2=A0DPDK-19.11.11=C2=A0for our application in which 4= construction threads construct packets periodically, place it in a circula= r queue and

a transmission thread pushes that packet by re= ading that circular queue.


In the lo= ng run, We are facing a crash in=C2=A0eth_igb_xmit_pkts()=C2=A0call = which is called during transmission.


After an inspect with GDB, we came to know that the non-freed mbuf address= is returned by=C2=A0rte_pktmbuf_alloc()=C2=A0for another packet dur= ing construction, even though that mbuf is still not transmitted by the tra= nsmission thread, which makes the corresponding construction thread to upda= te the same memory again.


It is not clear why rte_pktmbuf_alloc() returns the mbuf poin= ter before that pointer is not getting freed by rte_eth_tx_burst() call?.


We have created the mempo= ol using the call,

rte= _pktmbuf_pool_create(txMemPoolName, 16384,RTE_MEMPOOL_CACHE_MAX_SIZE,0, 2048 +RTE_PKTMBUF_HEA= DROOM,=C2=A0=C2=A0rte_eth_dev_socket_id(0));


Please guide us in resolv= ing this issue.

=C2=A0

Thanks,<= /span>

Gokilavani A

=C2=A0

--00000000000047853605ebd7dd51--