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 6B1DA45ACE for ; Mon, 7 Oct 2024 00:18:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED830402A5; Mon, 7 Oct 2024 00:18:23 +0200 (CEST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by mails.dpdk.org (Postfix) with ESMTP id E04D740265 for ; Mon, 7 Oct 2024 00:18:22 +0200 (CEST) Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-71e01207fa0so339186b3a.3 for ; Sun, 06 Oct 2024 15:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728253102; x=1728857902; darn=dpdk.org; 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=SAd0XeldVwOVW8IuSq6mGZi0Mv9UcID0QLpVGnryZrM=; b=NkdtXo5qLFpgieZsfjK6fp3rWrVLP75kz/rLICXta+NVkaw/dp63P6ATFV1X9po2/B Y5airsZduvq2oOL8GtgJX49mggH7LAAsZbb3zKoqjXVlYSdgKvlyvBYBKkLFaNBYXAPb lhopCuvoautju5qZQVXi7eb78HHrmAb2JnRTHnugCuiowm1nV+n7vHQdVUztpfQg0E9t WA/NNd3Vvv+Yw7WBfKMVV6VZrwjRWybMmTlRDti0FkXkm63eH/Nq6l96/66yNhR1aL3z Iv4GnWF2PbZXZGXfTvWO8l8YMLLqfW2Qn0L/5fYyRqMGxLOq/TFmu5XkcKCsiqL2T/6a AeLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728253102; x=1728857902; 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=SAd0XeldVwOVW8IuSq6mGZi0Mv9UcID0QLpVGnryZrM=; b=YN+cnUlbE+DrtBeoJmkez2oLsj+3xuLKx1+RU343qZHZhfYx+qsnzWtP80lqncQZR7 C+uYvjs824jA3MD2pO7Elq6ePPw1uFXltJlyOlt7G5kEUagslcqHkoZ+yZ3U4I6h/EhS 8zXrWh7TF/045T58/ohxtnAAB1iaM9ltyFpEcz1B4YuyKvagpeK6CXueErBvjBwCJJtl +A3yEC5QITiWoPcvlNXEEP9NTxVvR5UUkcWtMOXZxlQ9tl1RTN6vw1PrmFOBW3CkN7UL //6hMc6VCJY0e54oIwXDZcuPTcFZivicr05FVV+FnFVCF7bt2KBhMJ+09ssEb7IzeLKy wbSw== X-Gm-Message-State: AOJu0YyZsos+jD6PcZXrjHFv80H2eo/EDCiM4UqtnPLgF3Xpy+bKoK0r wF6yVEqqZdCIXYouWMaTl+7b9z/8Goe6R56VefZhp9qNoeknl1Bi+aX9rrkUpMI77ko3ywdI9Mr c X-Google-Smtp-Source: AGHT+IGKUokPu+9CxGTiKWZHboZMuKNAqfm+zb5IQt6fAkdkBU0RC0/vV2E2B2BwrJXHVOi7wOZWrw== X-Received: by 2002:a05:6a00:319d:b0:71d:ee1b:c84e with SMTP id d2e1a72fcca58-71dee1bca88mr8998013b3a.7.1728253101904; Sun, 06 Oct 2024 15:18:21 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71df0cd1f26sm3191544b3a.84.2024.10.06.15.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Oct 2024 15:18:21 -0700 (PDT) Date: Sun, 6 Oct 2024 15:18:20 -0700 From: Stephen Hemminger To: Alan Beadle Cc: users@dpdk.org Subject: Re: Force driver to free sent buffers? Message-ID: <20241006151820.489761d7@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 Sun, 6 Oct 2024 12:38:56 -0400 Alan Beadle wrote: > Hi everyone, > > Based on my thread from last week, I am using rte_mbuf_refcnt_update() > to increment the mbuf refcnts so that the driver will not free buffers > before my local readers are done with them. > I am also maintaining a queue of mbufs that local readers are finished > with, and periodically using rte_mbuf_refcnt_read() to see if the > refcnt is 1 yet, so that they can be freed or reused. > > An aside: Is there any problem with reuse of mbufs? Without actually > freeing and re-allocating it, that is? I plan to do this in order to > avoid having to link new mbufs to other reused data structures in my > application. > > The current problem is as follows: My application has a separate > unrelated heap (special purpose and bounded in size) and this heap > runs out of memory after a brief time because of having to track so > many unfreed mbufs. It appears that none of the mbufs are being freed > by the driver after being sent, and it looks like it won't free them > until it runs out of descriptors, which is too long for my situation. > > I have confirmed that the packets are being sent (received on other PC > with wireshark) and should be freeable. Is there a way to force the > driver to free sent mbufs earlier than when it runs out of > descriptors? > > Thanks, > -Alan Drivers are free to hold onto transmitted mbuf's indefinitely. Since DPDK does not use interrupts for normal Tx, the driver has to defer doing cleaning up either on next Tx or sometimes Rx. There is a Tx threshold that may impact some drivers, but not all.