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 AE1084C78 for ; Wed, 25 Apr 2018 11:57:50 +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-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 68B72140071; Wed, 25 Apr 2018 09:57:49 +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:57:44 +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-3-git-send-email-arybchenko@solarflare.com> <20180419164240.dgqwzsc6rubngo3s@platinum> From: Andrew Rybchenko Message-ID: Date: Wed, 25 Apr 2018 12:57:41 +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: <20180419164240.dgqwzsc6rubngo3s@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--23.034500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1524650270-iuLNEHzyibje 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 2/6] mempool: implement abstract mempool info API 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:57:50 -0000 On 04/19/2018 07:42 PM, Olivier Matz wrote: > On Mon, Mar 26, 2018 at 05:12:55PM +0100, Andrew Rybchenko wrote: >> From: "Artem V. Andreev" >> >> Primarily, it is intended as a way for the mempool driver to provide >> additional information on how it lays up objects inside the mempool. >> >> Signed-off-by: Artem V. Andreev >> Signed-off-by: Andrew Rybchenko > I think it's a good idea to have a way to query mempool features > or parameters. The approach chosen in this patch looks similar > to what we have with ethdev devinfo, right? Yes. > [...] > >> /** >> + * @warning >> + * @b EXPERIMENTAL: this API may change without prior notice. >> + * >> + * Additional information about the mempool >> + */ >> +struct rte_mempool_info; >> + > [...] > >> +/* wrapper to get additional mempool info */ >> +int >> +rte_mempool_ops_get_info(const struct rte_mempool *mp, >> + struct rte_mempool_info *info) >> +{ >> + struct rte_mempool_ops *ops; >> + >> + ops = rte_mempool_get_ops(mp->ops_index); >> + >> + RTE_FUNC_PTR_OR_ERR_RET(ops->get_info, -ENOTSUP); >> + return ops->get_info(mp, info); >> +} > Thinking in terms of ABI compatibility, it looks that each time we will > add or remove a field, it will break the ABI because the info structure > will change. > > Well, it's maybe nitpicking, because most of the time adding a field in > info structure goes with adding a field in the mempool struct, which > will anyway break the ABI. > > Another approach is to have a function > rte_mempool_info_contig_block_size(mp) whose ABI can be more easily > wrapped with VERSION_SYMBOL(). > > On my side I'm fine with your current approach, especially given how few > usages of VERSION_SYMBOL() we can find in DPDK. But in case you feel > it's better to have a function... I'd prefer to keep current solution. Otherwise it could result in too many different functions to get various information about mempool driver features/characteristics. Also it could be not very convenient to get many parameters. May be we should align info structure size to cache line to avoid size changes in many cases? Typically it will be used on slow path and located on caller stack and adding some bytes more should not be a problem.