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 B159EA0C43; Mon, 18 Oct 2021 11:05:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7B5DF40141; Mon, 18 Oct 2021 11:05:52 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 334C14003C for ; Mon, 18 Oct 2021 11:05:51 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 874AF7F519; Mon, 18 Oct 2021 12:05:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 874AF7F519 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634547950; bh=w8RZFwnyaXhP3jDdrc4g9dN0hgE6DxFBAN5wZhwNRbA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=rGZg/imbW6iPKCVXsKYHp7KglIFuDYS3lzQ+aQ/J5GfEF8PdsTQqUymv3P77HIn69 TSRO/IaeMsxs/iAOw8tcYYYaNv778Ns5Yu1fGQyRlq5wbxsJmvjyiqt/3cHX6Uq8iV ggWnesBFvQ1ufBzH83enmONMfKt0hUyYSO3k37MM= To: Olivier Matz Cc: David Marchand , Dmitry Kozlyuk , Ray Kinsella , Stephen Hemminger , dev@dpdk.org, Thomas Monjalon References: <20211018082635.2054-1-david.marchand@redhat.com> <79f4f029-ca13-6048-396c-232fe5ef5fb7@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <8d96bea0-abeb-090a-6589-62bd082bb7ca@oktetlabs.ru> Date: Mon, 18 Oct 2021 12:05:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mempool: accept user flags only X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On 10/18/21 11:58 AM, Olivier Matz wrote: > On Mon, Oct 18, 2021 at 11:37:32AM +0300, Andrew Rybchenko wrote: >> On 10/18/21 11:26 AM, David Marchand wrote: >>> As reported by Dmitry, MEMPOOL_F_POOL_CREATED is a flag only manipulated >>> internally. >>> This flag is not supposed to be requested from an application and would >>> probably result in an incorrect behavior if an application did pass it. >>> >>> Other internal flags may be introduced later. >>> >>> Rework the check and export a mask of valid user flags for use in the >>> unit test. >>> >>> Fixes: b240af8b10f9 ("mempool: enforce valid flags at creation") >>> >>> Reported-by: Dmitry Kozlyuk >>> Signed-off-by: David Marchand > > (...) > >>> --- a/lib/mempool/rte_mempool.h >>> +++ b/lib/mempool/rte_mempool.h >>> @@ -258,6 +258,15 @@ struct rte_mempool { >>> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */ >>> #define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */ >>> >>> +/** >>> + * This macro lists all the mempool flags an application may request. >>> + */ >>> +#define MEMPOOL_VALID_USER_FLAGS (MEMPOOL_F_NO_SPREAD \ >> >> I think RTE_ prefix is missing here since it is in a public >> header now. > > I discussed about this offline with David. I was ok to omit the > RTE_ prefix for consistency. > >>> + | MEMPOOL_F_NO_CACHE_ALIGN \ >>> + | MEMPOOL_F_SP_PUT \ >>> + | MEMPOOL_F_SC_GET \ >>> + | MEMPOOL_F_NO_IOVA_CONTIG \ >>> + ) >>> /** >>> * @internal When debug is enabled, store some statistics. >>> * >>> >> >> Should we make a patch to add defines with RTE_ prefix and >> add a deprecation for old flags without RTE_ prefix? >> >> Olivier, what do you think? If you have time to care about it, >> it would be great. (I'm unfamiliar with coccinelle yet). > > I was joking with David about keeping some work for 2022 :) > > I will try to have a look. As a side note, I was not that convinced by > coccinelle for simple replacements like this, because it does not > update the comments or documentation, it can (rarely) break the > indentation, it is slow, and the syntax is quite complex. > I dreamed to finish with renanamings in core libraries in 2021. May be it is to naive :( I see that rc1 is already delayed and adding a couple of more patches could delay it even more. I'm ready to do it without coccinelle today, so, it is a question to @Thomas and @David if that late patch will be considered at all.