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 DB39EA0351; Fri, 4 Mar 2022 10:56:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CBBE1427A9; Fri, 4 Mar 2022 10:56:48 +0100 (CET) Received: from m12-12.163.com (m12-12.163.com [220.181.12.12]) by mails.dpdk.org (Postfix) with ESMTP id 1D25E4013F for ; Fri, 4 Mar 2022 10:56:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=MDeqO c8J+I0wTUg5XFwCn2wKNDf8+DoKKW8VTp0/HsM=; b=l05arD1kALZNbzMTH4oa4 8UuOtzNEiWIBnxKETKZGuLtqtPLriN1NDhJibJbNx6RpQo+Pn+WMF+T42/qCFTHW 8nYDsuwXBYFfpRaLLsFde4gPOkMatR/gtQRVIWFLbf3tHZgZPCHXMoNdnVb+12ia +auDp1cmrSQ6kABBv9djNM= Received: from DESKTOP-ONA2IA7.localdomain (unknown [223.104.246.30]) by smtp8 (Coremail) with SMTP id DMCowADnU4hL4iFi04dhFw--.5544S4; Fri, 04 Mar 2022 17:56:40 +0800 (CST) From: Gaoxiang Liu To: chas3@att.com, humin29@huawei.com Cc: dev@dpdk.org, liugaoxiang@huawei.com, Gaoxiang Liu Subject: [PATCH] net/bonding: another fix to LACP mempool size Date: Fri, 4 Mar 2022 17:56:13 +0800 Message-Id: <20220304095613.1717-1-gaoxiangliu0@163.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: DMCowADnU4hL4iFi04dhFw--.5544S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7uw1rJF45ur4xCF4rCw47twb_yoW8Zr13pr W7GanxGF1DZF12qa17X3WfCrZ5u3WxXr1UKan5Za4fZayxAFn8Kr12yr1Y9rW8GrWvyrs0 yF4UA3sagF15CrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pR489XUUUUU= X-Originating-IP: [223.104.246.30] X-CM-SenderInfo: xjdr5xxdqjzxjxq6il2tof0z/1tbiQxm5Olc7XrlsngAAsg X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem: All mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated and are still sitting in the device's tx descriptor ring and other cores' mempool caches. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- drivers/net/bonding/rte_eth_bond_8023ad.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..f896195447 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,6 +1101,9 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } + cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? + 32 : RTE_MEMPOOL_CACHE_MAX_SIZ; + total_tx_desc = rte_lcore_count() * cache_size * 1.5; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? -- 2.32.0