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 99AFFA00C2 for ; Thu, 13 Oct 2022 13:09:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6F34942E8A; Thu, 13 Oct 2022 13:09:01 +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 9D41842C95 for ; Thu, 13 Oct 2022 13:08:59 +0200 (CEST) Received: by mail-ed1-f54.google.com with SMTP id b12so2096972edd.6 for ; Thu, 13 Oct 2022 04:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dz2VGx7VMHjrt803j4hjLVXHmipkEuy46hBX3OBoo2E=; b=WtsGVXmFXM0cYdbMrWtOdkB+ktqRFWaJMxwM5EI0n7wIy7p5iH2G3J9c/9wR2ER00s s6CTnzK3nhLbHAjvSMhmuzBwRW/RhBSeNg8agLgrOoJNzAIGbOlQVJ/AjbZIqO9J7C1I 973Dbe4btrZMu2GgDwEfsNybzflPTmxVkVWTn7snzV1qOanBpaYWj3DeoMuGsZAFnvVo RS9qRg5RMRy/B2YOmqZSEISfSLLWtSdm9GESHIkqj98L6SJ/P754YBnwNSPO/XdU2YVz SC7y3RJB7YPP3adYudR+xjf8Kj1cm1+Fg7/sWBsDt+UT8aR32REqVD69IkvKVEHm9Z1e sxVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dz2VGx7VMHjrt803j4hjLVXHmipkEuy46hBX3OBoo2E=; b=Y3yP9YCVr11+ZaESd7FoOahJ99Bki3ax6aOeLXXtnarG/igqUbOLjP68q+9cisR6bG yFuNRqX5OrW7UbzJvJ60k5yMLRSzuVld+qw+OvvCMtlHzISXZ7CCxya+IX/W3R5ktSV4 6BuDXLuesHpmWOoqbuIWsG8hEsWmGTLCjIaRtYawnNL9/QuseiqRwXIiyC9YganN/7Tb KPawNw3Gpxhp4mSAxaM69LGKeIIHtz73BmIinn+KttR1/59JVgyWjmp0TLGdTGUXcDTt bjjWUCLvApZVSRFNznOMdGzlsqE5PCNL7q7TqFEZLTHQ0oohPKJZwrsCtTZHITcaWeiA pUbw== X-Gm-Message-State: ACrzQf2qGayXumTeVj61WwQEt68bF1mPhUl5YN/4rtqSRRzPZQCC6KfI xkkYrRo8/7Dn1VQekbdzbN63HN9rT6N38ZiNLNNXWpPvDqE= X-Google-Smtp-Source: AMsMyM4YRew3ZQZeN2hsIN/6XL11d01BLGsegOopTkarOnKQqbs4U1s7IVxit4oahR2nO41Bp5VqUTK+2BDBLzUww/c= X-Received: by 2002:a05:6402:3896:b0:45c:93c3:3569 with SMTP id fd22-20020a056402389600b0045c93c33569mr9832153edb.37.1665659339063; Thu, 13 Oct 2022 04:08:59 -0700 (PDT) MIME-Version: 1.0 From: Gokilavani A Date: Thu, 13 Oct 2022 16:39:33 +0530 Message-ID: Subject: rte_pktmbuf_alloc( ) returns same mbuf address which is not freed To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000038c56f05eae889ab" 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 --00000000000038c56f05eae889ab Content-Type: text/plain; charset="UTF-8" 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 --00000000000038c56f05eae889ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

=C2=A0

We are using=C2=A0DPDK-19.11.11<= /b>=C2=A0for our application in which 4 construction threads construct pack= ets periodically, place it in a circular queue and

a trans= mission thread pushes that packet by reading that circular queue.


In the long 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 during construction, even though that = mbuf is still not transmitted by the transmission thread, which makes the c= orresponding construction thread to update the same memory again.


It is not clear why r= te_pktmbuf_alloc() returns the mbuf pointer before that pointer is not gett= ing 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,=C2=A0=C2=A0rte_eth_dev_socke= t_id(0));

<= span style=3D"font-style:inherit;font-variant:inherit;font-stretch:inherit;= font-size:inherit;line-height:inherit;font-family:inherit;border:0px;margin= :0px;padding:0px;vertical-align:baseline;color:inherit">

Please guide us in resolving this issue.

=C2=A0

Thanks,

Gokilavani A=

=C2=A0

=
--00000000000038c56f05eae889ab--