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 8775546003 for ; Mon, 6 Jan 2025 21:10:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FD6840A8A; Mon, 6 Jan 2025 21:10:43 +0100 (CET) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by mails.dpdk.org (Postfix) with ESMTP id 0D08E40A89 for ; Mon, 6 Jan 2025 21:10:41 +0100 (CET) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5401bd6cdb4so14675666e87.2 for ; Mon, 06 Jan 2025 12:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736194240; x=1736799040; 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=Eu9es571biUzl89kXCT9tkE+5/s1LXbbBwFH7AxU33g=; b=XG5sdPkX2/yUOcOMqOG+IeMseNFZtHmv0LQQ7f4HK6Atm06Z3ZZeucOIhbn8rcZ9+8 jkA1LPRL8+kRxbixj85FsaiyKsj0EDulRhuy4gOREr+uKw1MkSkkdSuycHvPGlcgvP+7 YgWTMd4AXV2rqjOAkP1z81pOhKUzTVwbdqgsyQTxbELkgCm9tQnoR5TBDb8auy1PKvud CtUnbJpVkWe/QXP9E6MzTnkXSkMbqerwB6YcI0SMpJMFeNbkxdniUsMKdJPzQiX70ZW/ S+v73cztLoHfx6Qhty/FyipAj6udGkljDOeT2ios9627wp3sCry661BTR80saGOGgih8 3YWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736194240; x=1736799040; 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=Eu9es571biUzl89kXCT9tkE+5/s1LXbbBwFH7AxU33g=; b=S/Ij993aYBSgWKKpgbr0gSXRrK7v7QoDeOJZA/VY/Wfre07eTvnhC+qNQ2zsnZ+q9B sPBZ6OJzyA41GAUrX0Lv/DmFJGrvXoiwxAJbWINh8A4BdKZ13mqyLpvyG+2878j0FiBw 9KV99EwAJlqfo1Hb5XrJRCWIt0yPm19ZIHNBc6YitZGhV+Wcj0SVzdhDYvsXQ6sU2zfx GfH6WqSxX2vtpPcQR3Nmx8InaeoHEAXWPk4O3gVsi5JZagVqrWgTOs36XMbQcRtmgeun 5Yi0kgn+zczNL2S54bkbtXMdXQgIvDOXWsmjZgAVqUNylrgqR6aguL1MFvce01P9GTQN m9gQ== X-Gm-Message-State: AOJu0YwXO4/2t2jleOF7+mEClXPNguu6kZy1kDi+eDPz/i1c9Tu+/Kb7 Tg+hBKs3phk10v9/6beMaTdXNaQaNx2Uf1OzX8IUXYAfXkZZi67N X-Gm-Gg: ASbGnct7zNcOpQZp3Cr9LQ7oSUkVTywd9o+F+HcjGBvgrzvgG4aECmFhdSG7TtW+A9o NiXyR6Evo5/HtIvSChN1OOlS82MtnYzyDerez7H2G9tQmVcM18beNYTPhQom3EgbNTOfh7wKTYx AW7EAeTBLXV3FEp7xbrbHVsPFMMihlTfzgkoZURPRFEPuerj5nQ+fsmEZlhABn4dv84vAWHTsvN IDdnsPsENS9xwKo8ur7RDGtZFvFMU7WSW2xODltHc0Z/KE4S6NB1phWMeRjfJ9S9SKeTkltgyqN QMcpifLpGC350ztLJ54I+iGlUASK X-Google-Smtp-Source: AGHT+IGstyvtFlHqBTenb45jEUTZOVPKsNGdntwVDkfBVJW5vLwVwjKHXKxrDRBJu7Wgt66Lf20xTg== X-Received: by 2002:a05:6512:2349:b0:542:6f70:b484 with SMTP id 2adb3069b0e04-5426f70b6famr2665588e87.12.1736194240014; Mon, 06 Jan 2025 12:10:40 -0800 (PST) Received: from sovereign (broadband-109-173-43-194.ip.moscow.rt.ru. [109.173.43.194]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-542238136b3sm5057804e87.150.2025.01.06.12.10.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2025 12:10:39 -0800 (PST) Date: Mon, 6 Jan 2025 23:10:38 +0300 From: Dmitry Kozlyuk To: Alan Beadle Cc: users@dpdk.org Subject: Re: Multiprocess App Problems with tx_burst Message-ID: <20250106231038.59a6fc4e@sovereign> In-Reply-To: References: <20250104214032.04eb6d25@sovereign> <20250105010148.1ef26333@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 2025-01-06 11:05 (UTC-0500), Alan Beadle: > There is definitely something going wrong with the mbuf allocator. > Each run results in such different errors that it is difficult to add > instrumentation for a specific one, but one frequent error is that a > newly allocated mbuf already has a refcnt of 2, and contains data that > I am still using elsewhere. > At each call to rte_pktmbuf_alloc() (with locks around it) > I immediately do a rte_mbuf_refcnt_read() and ensure > that it is 1. Sometimes it is 2. This should never occur and I believe > it proves that DPDK is not working as expected here for some reason. I suspect that mbufs in use are put into mempool somehow. Which functions do you use to free mbufs to the pool on processing paths that do not end with `rte_eth_tx_burst()`? You can build DPDK with `-Dc_args='-DRTE_LIBRTE_MBUF_DEBUG'` to enable debug checks in the library. Unless `RTE_MEMPOOL_F_SC_GET` is used, `rte_pktmbuf_alloc()` is thread-safe.