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 A547D45B04 for ; Thu, 10 Oct 2024 17:17:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 69365402F1; Thu, 10 Oct 2024 17:17:47 +0200 (CEST) Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by mails.dpdk.org (Postfix) with ESMTP id 7A056402E8 for ; Thu, 10 Oct 2024 17:17:45 +0200 (CEST) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-2883e3f5419so452267fac.1 for ; Thu, 10 Oct 2024 08:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728573464; x=1729178264; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=osk1fp1zsNMecdxUxmFcYROgh7HANFAdcMkOlJmCRtk=; b=JKvzpVCzD16c8SQhgjYv+QHjWfOmtLDL2suOjKCSJh74k5bojRM8/EAFpw06UE20ZK /lslI0fjSOquTxNoZ/yR29oZ2VCLH26SGATJDdcvNLc97dl83ano94z6Wlu0xo6ST6lX 587KbXII6GsP3ScB/fwmFP7b1p3S2HiwCOcG8a107N4+uxUWj6Z7WBJjjfbke2MjBAAY GqldIHL/Z3O9jgDJMhw7QEAmaSjhN/59jGB/Ly2aieFlfQV6xc3vBMv1vBTQvid5kv+0 iqyvrHJKWZmKULR7m/UZRb9S4aTEVrEeZxxYCZQvRfQOL9gyGKcsrgvXqcasDEnSACc6 AsUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728573464; x=1729178264; h=content-transfer-encoding:cc: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=osk1fp1zsNMecdxUxmFcYROgh7HANFAdcMkOlJmCRtk=; b=uiMQ3756UveDgLHguHK44KJA93ysuTvVJxJVpn7ZKwQfukz0TEYSTssgAnRRPY8p5y pHnhX/SYITw4R9rkNhfhSpdCS1HLgUkrcxjcb7XucNQ9tj4lchV7hPtd6fjIEanJSPx7 1XpzRgDFBCT0q8HMCW0T4qPh8cX3aWu8b9t+Kod8XNkUHlncEwhSYsmYUdnOAWD8c9i7 b9ZXqODY33P8DyUQ27TtvH8E0MzTXvhdROF+FeA1HH43OtlbOp/zltYJf6goKjewXTTG 8vMjcquCLN3lBbahDl1YukFGB96OlFwd9HBT4m4XNrUjZt+t/7qVMoI7yNfVZOO/5vCE 2++A== X-Gm-Message-State: AOJu0YzmkuY+vpnmSc2bt6e6uOJQfPWI3KbH2Q4/OShBT7ZA3ZO4rxvJ OyibvQFX7kqAwsdYIYsj9sz9KcM2bil3PUsaB5yq+7taY1NtRWP19Yt65TC9Wu6oDFFdcqZuywA K73cSutp4aFyVAwaz01ZEVafqxrM= X-Google-Smtp-Source: AGHT+IFFVbAfB7OCgFALGeoclP0Br+ioRRhazYikEE5NmE7vv9kR93nXiYcthU0SvtcjWfoK0XOC8Vu0Un/gVSfdl4k= X-Received: by 2002:a05:6870:7251:b0:278:3de:c8de with SMTP id 586e51a60fabf-2884a7f7431mr4203327fac.24.1728573464607; Thu, 10 Oct 2024 08:17:44 -0700 (PDT) MIME-Version: 1.0 References: <20241006151820.489761d7@hermes.local> In-Reply-To: From: Alan Beadle Date: Thu, 10 Oct 2024 11:17:33 -0400 Message-ID: Subject: Re: Force driver to free sent buffers? To: Stephen Hemminger Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Oct 10, 2024 at 10:12=E2=80=AFAM Alan Beadle = wrote: > > On Sun, Oct 6, 2024 at 6:18=E2=80=AFPM Stephen Hemminger > wrote: > > > > Drivers are free to hold onto transmitted mbuf's indefinitely. > > Since DPDK does not use interrupts for normal Tx, the driver has to def= er > > doing cleaning up either on next Tx or sometimes Rx. There is a Tx thre= shold > > that may impact some drivers, but not all. > > Stephen, > > How would I attempt to set this threshold to see if it impacts the > driver that I am using? I cannot find any EAL parameters that seem to > correspond to this. > > Having to re-allocate a new mbuf every time will hurt performance, > especially since most of the packet header values will not be changing > across packets but will need to be reinitialized in every newly > allocated mbuf. I had really hoped to recycle a set of <100 or so > mbufs. (Stephen, sorry for the double email, forgot to reply-all). I believe I have found a solution. I'll have to investigate the impact on performance later but advice/analysis is appreciated. I initialized the pool with a limit of 128 tx descriptors and set the tx ring buffer size to match. Once the ring is full, the NIC seems to free things as it goes, resulting in having no sent-but-unfreed mbufs most of the time. Please let me know if there's any major issue with this approach and if there's anything else I can do. At least this behaves in a way that I can design my app like I planned and I'm hoping it results in non-bursty latencies and good performance. -Alan