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 75EE945A7B for ; Sun, 6 Oct 2024 18:39:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ECA77402C3; Sun, 6 Oct 2024 18:39:09 +0200 (CEST) Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by mails.dpdk.org (Postfix) with ESMTP id 20EF54025D for ; Sun, 6 Oct 2024 18:39:08 +0200 (CEST) Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-260e6298635so1866446fac.1 for ; Sun, 06 Oct 2024 09:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728232747; x=1728837547; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Ah3ODIFfCAyF1r4UOKnFmYnyF75o8V1uZs31OIfIkp0=; b=E8yP56haiF2fdzeC4bLfTNlm6OzE5Y1M5htxeUsCC1Rf8jLbUsGygq/Uvob6nAAmnu BFWrl9dBkTkv1YxPkl2M1Sw2na8KnF/nh38AGxrTEEovC7L4qNiTNChkE3CwaxZFkK2a F9oictshbUqIKOiGPa+q1N5A2wjL/Cs7twgnYRL5qlr9c+GMJwiDP0pipl3bOUeSQGEK Na+8lqqSPLVrgG3rnCXGPG8jWaSQ2gssYDoatr8PLc2pIQdfZs4UdjwbK9n0A22Cc8AC UbPBRRZxMZvULmY1pwAWJQMKY5E9no/HZeUyPzfJpmmvJrKnZTyO0Bi87HR910aFmWZi y8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728232747; x=1728837547; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Ah3ODIFfCAyF1r4UOKnFmYnyF75o8V1uZs31OIfIkp0=; b=fLTX3UQ1CJ71vGCj8HwUUdH0ac1yZXPoqT29XxnLwAJkc0di3++hJ/vZDYeAyqknlB ljopvHPfIxbNawHItG8RwI5Qfa50+jANy9zaeKOW8iXZ1hmvBL8ky+cGTBImq3Rk8Bmy ScWX22SJRKfpHOH80hvtqjXobvGFDrZOAjkyfLM5p/dC7ChChfME1U/jUfMlbhZKswTh M/iBiv51q+V+9avJxFM1h+yR0rUy6liUtwJUePRLw+vOTW652IYPk5YaHE8S5Cvq7pRw VCO+4EY3WrZ4OBaYdAHtrBedGrls6IPzH4woIuIl9Ar+vNSHwfm0BrfXyr9U5hx02/Jn pnyg== X-Gm-Message-State: AOJu0YxoQV6mPshQoZdeoOSPI9EVFetDNZCsc8m/mgSkKSMZEoo7Ojva wulgwTARlVYb/pr4094KtOhWS5gL+YkO2zkdevjqq980WVMbFJM9AUDYgq0rGuXoRXRiowpdHbv dx7SkoI6/QHzn3P7inOIbQ9fuOCkJc2dr X-Google-Smtp-Source: AGHT+IEzWRjmSN4a5LrEJBYZkK/yKR2DnbX/jVKm4PY4ll1P1drnTMRPkGW73Nph9WjHPRt48APcyANonGfn9/b05ic= X-Received: by 2002:a05:6870:d628:b0:279:b5ac:d1c1 with SMTP id 586e51a60fabf-287c3abefe6mr4998321fac.8.1728232747111; Sun, 06 Oct 2024 09:39:07 -0700 (PDT) MIME-Version: 1.0 From: Alan Beadle Date: Sun, 6 Oct 2024 12:38:56 -0400 Message-ID: Subject: Force driver to free sent buffers? To: users@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 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