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 4EA7242A5F for ; Thu, 4 May 2023 18:14:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41BE741144; Thu, 4 May 2023 18:14:55 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id AFF58410DC for ; Thu, 4 May 2023 18:14:54 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-6435bbedb4fso874680b3a.3 for ; Thu, 04 May 2023 09:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1683216894; x=1685808894; 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=cD6u2mvPIKae7MtvCfXjITfvjU9+Vqt2HTKcTxlJo6Q=; b=TiHjWx8b5/SsoMv+iGW51z0oPZdd6TpPL3UI/MhrBeGfyKg8LjtdgpwmhgJCaQllYg 50csPSKDv7CJB179NdrySJKjsj8WXwoo8/CqxQVeiKvh3AftfvmEkQ2EXkgjEtQuXcZ9 zsFa+/XMsOmNS3gN3unhERHKJ1GkX2tGTsBvHRCju2L843U5fTn08vuOxLHmqHB2t8Qf M0cZTTem3i0cepWFJ6atB+7aQFcNtj52npz4JcME56tf9hGD7YGxtVKdLTKue3wfi9c0 MfNrnfltUG8wm1YVKdtPFyVSdHdmm8/cVv2EFGC1WfBuQDQyTEgeCpMOyTi8QM4rUqPI pSwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683216894; x=1685808894; 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=cD6u2mvPIKae7MtvCfXjITfvjU9+Vqt2HTKcTxlJo6Q=; b=k9AaB3BBOTMdWNTD/He1aiVMHT8I2oY8gDVxL92QngJLUnF7SBvyy8cedyCv53Xn37 yqwLo9c7q5ur6/sORInnGjlzC/AH1P69eWYn0e0u1CWJR4aMQZ1lORewOSiAwN1IpK0/ Jsf+Dw3sxREwiZjZA77Ez7JpUNy0tEx05plT+VmAqg/qGn7bkgPHgYhfsj+Rapfnf6AW 4+eOtoaFOjle/YJgquGhzbECOSRiMC2yIYXPD+i/w7UN7JOQnNvoxaVsBYo3gBE380Xj YUU/ufRtjz3UwuRTMdv9Mw3bsElDZPZfkTvkYsQd1Py9TKaE5OEP1wnfZO5CGqEHDxQK TAZA== X-Gm-Message-State: AC+VfDy6sHbd6CW+4Q/gigFXRDAruXz/3k1ZGkdsSSQviQum30/IT3NX pGjysgKcwy6zELbY8QP3ElecTbNs5xbYeuSmXRfBWm61 X-Google-Smtp-Source: ACHHUZ4zeulhT2ADED9+DcIxYC45F9VRbPFWk8agKnZxYPVWB4sTN3URBo0hH+WSpaSR7vf1JkuxDQ== X-Received: by 2002:a05:6a00:c83:b0:635:c8e4:ed0f with SMTP id a3-20020a056a000c8300b00635c8e4ed0fmr3559191pfv.11.1683216893829; Thu, 04 May 2023 09:14:53 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id 188-20020a6219c5000000b00640e01dfba0sm19359694pfz.175.2023.05.04.09.14.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 09:14:53 -0700 (PDT) Date: Thu, 4 May 2023 09:14:50 -0700 From: Stephen Hemminger To: Yasin CANER Cc: "users@dpdk.org" Subject: Re: DPDK 22.11 - How to fix memory leak for KNI - How to debug Message-ID: <20230504091450.4520f2c6@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 Thu, 4 May 2023 13:00:32 +0000 Yasin CANER wrote: > In default-testing kni application works as below > > > 1. Call rte_kni_rx_burst function to get messages > 2. Then push to other KNI interface via rte_kni_tx_burst. There is no memory-leak because kni_free_mbufs is called and freed unused allocations. > > On the other hand, in my scenario > > > 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel > 2. Then try to free all messages via rte_pktmbuf_free > 3. Freed 1 unit and 31 unit is not freed. memory leak > > Other scenario, > > > 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel > 2. Push to ethernet_device via rte_eth_tx_burst > 3. There is not any free operation by rte_eth_tx_burst > 4. Try to free via rte_pktmbuf_free > 5. 1 unit is freed 31 unit is left in memory. Still memory leak It looks like you are confused about the lifetime of mbufs, and the "ownership" of the mbuf. When you do kni_rx_burst, one mbuf is full of data and returned. The other 31 slots are not used. Only the first mbuf is valid. When mbuf is passed to another DPDK device driver for transmit. The mbuf is then owned by the device. This mbuf can not be freed until the device has completed DMA and is transmitting it. Also, many devices defer freeing transmit mbuf's as an optimization. There is some limited control over the transmit freeing via tx_free_thresh. See the DPDK programmers guide for more info: https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html