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 8071F45AAE for ; Fri, 4 Oct 2024 15:49:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 035B540E34; Fri, 4 Oct 2024 15:49:11 +0200 (CEST) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by mails.dpdk.org (Postfix) with ESMTP id 748B24066D for ; Fri, 4 Oct 2024 15:49:10 +0200 (CEST) Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-84f1ac129c7so818654241.1 for ; Fri, 04 Oct 2024 06:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728049749; x=1728654549; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cn+l9BlviiT7/19AdEXzMQP5eohudMciSNVyekleubc=; b=SdJGW0Hf+psJJnsqn6qX5WtzpChQW/ibGH32fj+uqxxESqHOnyzIgyLOK41Wb9RgPE uDKh1BufsVgYFicjl/bEEBH2Z2sluTMKT2yIfmTo1JrfAH4K+eoz8cdTWcWABqCpqpsM YW1c7uXApZVHjFOiRua7oX78Cn2mabMVuEUuj5NnEjT73zQuLjOchWS6j3YPxh+gCUzR 9CK+n7tH6oaOAk+iSbNxW9T4oZI8JJti3gqeK59H3mZtplbSH9Xoqw0RTPyMtHg7NIT8 o2352MqYu8M+429gNo3lyFqRK3th5mPmeDo4JBW1Nf6mlhiY1n67LIMmRO6TlODPpclk P0QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728049749; x=1728654549; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cn+l9BlviiT7/19AdEXzMQP5eohudMciSNVyekleubc=; b=K/3xpYwtYgqTu8dVeLmp610wS/aWh/rRNE3LzkTqJBp5mHPVCVRTlxF2TXSwM+Nizp +7yUMBgxQ/W4EAr0S4CzolwTGZuyMWkwrZhSHvDLX5PE2CAKATFIL+8c5pGYa6XotK/J t45EejMl3SJndWxx6GKXIKzhAK5kZM2x3TIUQHYUNu6kMeWPhMKW/hXWqqcme73iT7BM OhKSzrLDQP06OeQsvhL+c7tt0De+SPNfEVyDsA4KuneQIh1cOrnhikHhBmW3Wp+We9no MsLQbJss+km2XGlIL91LJRVoBMyua/gu4xq4SpGo/24NKcYMt1+SYSnbvSQ7bQ6Sb5Ai DNAw== X-Gm-Message-State: AOJu0YxW2BlaZ0oZBdFbpFCixhFRb7gpjSGvzhAo4wEcUOllN7nS5RzD PrxLk4Y5lxMkdiIHYAreaZwiuiv6oa6xRjTMKhSTxumBDifmWSQyU/b5d4imVRFDxEECHDGEXPo 9R2L8GLDrfuO4n7+jTCLdX2rH6E9tR2f5 X-Google-Smtp-Source: AGHT+IEzpJg1Dg2c3Hh3TEs7INpevbGjfcZuLtGJXS7NAFZueHqoX1VJpgksNPFmQv6qeDFVi6pjs0bJS0BV13V7QJ0= X-Received: by 2002:a05:6122:2524:b0:507:8753:492a with SMTP id 71dfb90a1353d-50c855a766fmr3390592e0c.12.1728049749581; Fri, 04 Oct 2024 06:49:09 -0700 (PDT) MIME-Version: 1.0 From: Igor Gutorov Date: Fri, 4 Oct 2024 16:48:33 +0300 Message-ID: Subject: Mbuf pool cache size in share-nothing applications To: users@dpdk.org Cc: andrew.rybchenko@oktetlabs.ru, mb@smartsharesystems.com 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, I'm a bit confused about certain semantics of `cache_size` in memory pools. I'm working on a DPDK application where each Rx queue gets its own mbuf mempool. The memory pools are never shared between lcores, mbufs are never passed between lcores, and so the deallocation of an mbuf will happen on the same lcore where it was allocated on (it is a run-to-completion application). Is my understanding correct, that this completely eliminates any lock contention, and so `cache_size` can safely be set to 0? Also, `rte_pktmbuf_pool_create()` internally calls `rte_mempool_create()` with the default `flags`. Would there be a performance benefit in creating mempools manually with the `RTE_MEMPOOL_F_SP_PUT` and `RTE_MEMPOOL_F_SC_GET` flags set? Thanks! Sincerely, Igor.