From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 177E12583 for ; Wed, 25 Apr 2018 11:49:32 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id D5D41B8005D; Wed, 25 Apr 2018 09:49:30 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Apr 2018 10:49:26 +0100 To: Olivier Matz CC: , "Artem V. Andreev" References: <1516713372-10572-1-git-send-email-arybchenko@solarflare.com> <1522080779-25472-1-git-send-email-arybchenko@solarflare.com> <1522080779-25472-4-git-send-email-arybchenko@solarflare.com> <20180419164130.ghqbhz6qvkwhnnua@platinum> From: Andrew Rybchenko Message-ID: <90fcec92-bef8-5f8d-b145-41ea35e6120a@solarflare.com> Date: Wed, 25 Apr 2018 12:49:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180419164130.ghqbhz6qvkwhnnua@platinum> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23804.003 X-TM-AS-Result: No--13.318700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1524649771-XxivL3xcB8GT Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 3/6] mempool: support block dequeue operation 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: Wed, 25 Apr 2018 09:49:32 -0000 On 04/19/2018 07:41 PM, Olivier Matz wrote: > On Mon, Mar 26, 2018 at 05:12:56PM +0100, Andrew Rybchenko wrote: > [...] >> @@ -1531,6 +1615,71 @@ rte_mempool_get(struct rte_mempool *mp, void **obj_p) >> } >> >> /** >> + * @internal Get contiguous blocks of objects from the pool. Used internally. >> + * @param mp >> + * A pointer to the mempool structure. >> + * @param first_obj_table >> + * A pointer to a pointer to the first object in each block. >> + * @param n >> + * A number of blocks to get. >> + * @return >> + * - >0: Success >> + * - <0: Error > I guess it is 0 here, not >0. Yes, thanks. >> + */ >> +static __rte_always_inline int >> +__mempool_generic_get_contig_blocks(struct rte_mempool *mp, >> + void **first_obj_table, unsigned int n) >> +{ >> + int ret; >> + >> + ret = rte_mempool_ops_dequeue_contig_blocks(mp, first_obj_table, n); >> + if (ret < 0) >> + __MEMPOOL_CONTIG_BLOCKS_STAT_ADD(mp, get_fail, n); >> + else >> + __MEMPOOL_CONTIG_BLOCKS_STAT_ADD(mp, get_success, n); >> + >> + return ret; >> +} >> + > Is it worth having this function? Just to follow the same code structure as usual dequeue. > I think it would be simple to include the code in > rte_mempool_get_contig_blocks() below... or am I missing something? I agree. Will do in v3. [...]