From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by dpdk.org (Postfix) with ESMTP id D1E9D2B83 for ; Thu, 23 Nov 2017 22:05:12 +0100 (CET) Received: by mail-qk0-f170.google.com with SMTP id 78so22350506qkz.0 for ; Thu, 23 Nov 2017 13:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xvctdjOC7rjVXQY30BvtoOlJ3YDtSCf7/jiNi/9D6XI=; b=OIRY3qCOJ+phu/iBpbxC01NwQdqAg6wRLA0Ya5mPwSYbHPwQggIrDGpySpTThOFvuh +5di46KZxAgb0SuklOwjxULWqYRWzWsNpWVHSLF7rZUWc3y0r8fprWszFWYdRa6DoewS xpw+IqnrqDoecdEzLjOgrnj4n9sMfQWN8eESn55ieu6QMgVVIOij+Ax18U2mqBq1RjkH xaWAuAqncuJOp4B0kVuT8puhYJJ3VnLKM0miybHOV4X0yjdisj56zJFCYuS2BS/IA9RX W3yt4EYiOLbeh5kZuBGTWnTCAlFu9mf/wumQVft/1ON8zK6QibC95rIa/6iOshjcI8/J HE5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xvctdjOC7rjVXQY30BvtoOlJ3YDtSCf7/jiNi/9D6XI=; b=lgA6Zx3FzSABcRfehZbPTvn7fYT+MPXoHOXPAn3/Szj7owZ+yg5oEP/VU4Gyrvpqer Co18k4cbwCVWonB2lcJR3PQVeHT7dKZhu+ACfTmq8cFxj3qs0eX3hXZSJuCVpu4iPowT lwSBtcrJdWdhdFinIK2xqoGkcD6eaY+qNwS4KQ5LVciIDC4RNlELaPs53XjH0avxejlb ZrloTezaXRrSIXWob+zzqNcKQ/xXzbmJgvgO2eE8FFaRq1RaL+YXnIq1LkXh98b0OKRv yxQ/H+WSmgjdRMjwiRSIRmn8MFvxW1bZnG5PQcZAEoCXpnfClP07asy7Fn24IG5zW6TD JklA== X-Gm-Message-State: AJaThX6JmX2wCktugcdpdQtKP52/FiUNZeSyt/HGPbXHroDTIfIILnC1 xxnfmqxeJ3LB2qkgh+w6o37stYJ05bWp2PzZbgiEww== X-Google-Smtp-Source: AGs4zMZP3iWAFePVHiQ0LteTbbtwi903/Lv1XEgwLfiP/Z7PvPQBhMwI8Fq2DGwEWiWsBbcdsv3lMUI3OFceyBeVego= X-Received: by 10.55.22.23 with SMTP id g23mr39864644qkh.231.1511471111930; Thu, 23 Nov 2017 13:05:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.23.68 with HTTP; Thu, 23 Nov 2017 13:05:11 -0800 (PST) From: Roy Shterman Date: Thu, 23 Nov 2017 23:05:11 +0200 Message-ID: To: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Question about cache_size in rte_mempool_create X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 21:05:13 -0000 Hi, In the documentation it says that: * @param cache_size * If cache_size is non-zero, the rte_mempool library will try to * limit the accesses to the common lockless pool, by maintaining a * per-lcore object cache. This argument must be lower or equal to * CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE and n / 1.5.* It is advised to choose* * * cache_size to have "n modulo cache_size == 0": if this is* * * not the case, some elements will always stay in the pool and will* * * never be used.* The access to the per-lcore table is of course * faster than the multi-producer/consumer pool. The cache can be * disabled if the cache_size argument is set to 0; it can be useful to * avoid losing objects in cache. I wonder if someone can please explain the high-lightened sentence, how the cache size affects the objects inside the ring. And also does it mean that if I'm sharing pool between different cores can it be that a core sees the pool as empty although it has objects in it? Thanks, Roy