From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3518EA3168 for ; Wed, 16 Oct 2019 09:22:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9C3441E8E0; Wed, 16 Oct 2019 09:22:45 +0200 (CEST) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by dpdk.org (Postfix) with ESMTP id 2E9041E8B6 for ; Wed, 16 Oct 2019 09:22:44 +0200 (CEST) Received: by mail-wm1-f52.google.com with SMTP id f22so1526488wmc.2 for ; Wed, 16 Oct 2019 00:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=C9UYFYqr8Cpp9PSkxzg1fo0PRbm4ft5K4M8gM0eayiQ=; b=GNf7LAShHljRzgbECpEsj3FUUatkCQFZXBuRzSF2Jp/qJQzLzlWGridDlc8jXUPGGP T4O2imByi3Ff61H/fAaOYZGVhs2weYF8D81OeRFPPqS6T2dEW7SGpgSxpvIj3q93eLCi 8CZAHQBYggt4U9ZRV1Sc/eIxWZpysaG8VRLQx6Pw/BF/1+GAr6tUWUI8Mmy25t39vErI hS2W9PzaKdwv7P/zqvMK7RVu0kz0UzIjmPL+VNOX/ubHqOtOs7sp+8gvC/ao4h0/3i6P IH5LzvjRohlbORU1M5lU1Kxbxt33FCkDgqyWaEPPJYuZnZETVssqGlgUJ/mFeJF8fASo D98Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=C9UYFYqr8Cpp9PSkxzg1fo0PRbm4ft5K4M8gM0eayiQ=; b=q8uA5laX07KCe4G8d73L1XYr8HMteJAivAiBCot7T8LqX7hXv+3zYqg5P+hu/1tdrE 10hpVBQogdFrRZ9fCcQoyUXv6dLxiz0SMmZFgX1Bn4D+Wk++qwwydQYtDMzLRONFmceY VjBc0uPpJIPt3oC35voNljMl0uMrcdFlpwteWTTdCSi1V8qEXXg0Jbbj35Akq5DUV7AW FQJ7aPvVyxEbF39foQ3iaVkvd1FeyIlebEEAwV6keGd3DQ2Ux9KLZk5AFnWctdg+iVQv NsIea1LG09TBj1G23uj17ALpYneUFDJZQ3OonTEuYlknFpd2J5Sp5hoN7iw4dsKArHx7 gAUA== X-Gm-Message-State: APjAAAWEf1YFOrtJ3/kkuz5Zu7QAfwgtjiAtzMdhOkPR7Y+g3n7i1iYi NTnKljYJcNzXR2hIt+5XU7klGJlUub0= X-Google-Smtp-Source: APXvYqxku1+sFO54xw7GS280UoefWaU3kc50K+dMt9ryKgEQhaLAwMY5i4qoGlWpKESZRsJJ53r4PA== X-Received: by 2002:a1c:8043:: with SMTP id b64mr1909263wmd.145.1571210563792; Wed, 16 Oct 2019 00:22:43 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a6000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id w22sm1451195wmc.16.2019.10.16.00.22.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 00:22:43 -0700 (PDT) Date: Wed, 16 Oct 2019 09:22:42 +0200 From: Olivier Matz To: Morten =?utf-8?Q?Br=C3=B8rup?= Cc: Andrew Rybchenko , dpdk-dev Message-ID: <20191016072242.3dr7i7xmdokztjd4@platinum> References: <98CBD80474FA8B44BF855DF32C47DC35C60B78@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60B78@smartserver.smartshare.dk> User-Agent: NeoMutt/20180716 Subject: Re: [dpdk-dev] rte_mempool_get_bulk uses either cache or common pool 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Morten, On Fri, Oct 11, 2019 at 01:24:00PM +0200, Morten Brørup wrote: > The rte_mempool_get_bulk() documentation says: > > "If cache is enabled, objects will be retrieved first from cache, subsequently from the common pool." > > But __mempool_generic_get() only uses the cache if the request is smaller than the cache size. If not, objects will be retrieved from the common pool only. > > Either the documentation should be corrected, or the implementation should behave as described, i.e. retrieve the first of the objects from the cache and the remaining objects from the common pool. That's correct. I think the documentation could be updated. Maybe something like this: * If cache is enabled, objects will be retrieved first from cache, * subsequently from the common pool. If the number of requested objects * is higher than the cache size, the objects are directly retrieved * from the common pool. The put() suffers from the same problem, but the actual behavior is not easy to describe. We could add this: * The objects are added in the cache if it is enabled, and if * the number of objects is smaller than RTE_MEMPOOL_CACHE_MAX_SIZE. * After the operation, if the cache length is above 1.5 * size, * some objects are also returned to the common pool. But I feel the comment is just a duplication of the code, but in english... and there's a risk that they become unsynchronized in the future (especially because the comment is above rte_mempool_generic_put() and the code is in __rte_mempool_generic_put()). > PS: I stumbled into this while writing the unit test for mbuf bulk alloc/free. > > PPS: It seems unit tests for mempool bulk alloc/free are missing. :-) > > > Med venlig hilsen / kind regards > - Morten Brørup > >