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 A676FA0C4E; Fri, 15 Oct 2021 14:13:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43965411CB; Fri, 15 Oct 2021 14:13:59 +0200 (CEST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mails.dpdk.org (Postfix) with ESMTP id D6058410F1 for ; Fri, 15 Oct 2021 14:13:57 +0200 (CEST) Received: by mail-wm1-f49.google.com with SMTP id j10-20020a1c230a000000b0030d523b6693so2771346wmj.2 for ; Fri, 15 Oct 2021 05:13:57 -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:in-reply-to; bh=pi2LoQIZLgLiWeNjeulCJtSrYH8Hia5C1E20CRZ4nhk=; b=APsm2kZcwjpXXbpWDHWBefs2jhV8Z8+nxhInNQSY9d4fcEhTRO/qHt6VbseRAnQk4g rKU+BPSOzyYnifeyOfsImaj6JxEN+M+3wh5+OzGkUjTQKgzGZWi7MXLi59gPyLtsxri9 1m0JMVN9cZfpKW1FXcKm68VGuNuSe+9m3jIgJ8yADmVYNrdgcTEgPCA857+O6xnkqVEc TA3uDjtCO36L94E9ERrHUhD+dQCkdN4ESx6+aacKr2WlUbhZq3PL3IlHqY7CZWHds39A 3q8mNW44eRtL17AH+Vlq7wSCZNNFpmvnU5fKc5eyNp4OztEp7U+lAzkwt/AaQ4hdCYBm w0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pi2LoQIZLgLiWeNjeulCJtSrYH8Hia5C1E20CRZ4nhk=; b=V+/zcpijk093rnZI4y+Wk/WAekcoN6NFolSYfv5nQuPSfil8iqJIiEzzCzc4+xTE59 elf/uv0sGVXrBxdoz48WNbzrgVDoOrFmbq34waefU3OGRsgAmtEfWL3uS+dPJAy6hPxO YZfYCr9KA9QyjVk77bBr0x1NsmbJOAe5j7pJuE167szksyWrINgjsvT/pDWSPKDKm3uE x1w/cx56/ZunhqkBe5Lf45A1sctWi1eZg0q7YO2HMfh5jHKovLpjemp09fM7wEWSo4Fk 2qJGHFWxBn/q2tVpp+woQYnszrEbdVYYeWKxfn9jW3fX8cJDQziWQ4W9uDN5snbavNie vbDA== X-Gm-Message-State: AOAM530icCgYcWzWpSTrfkw2JXVnzqLWWDbASO9AeJsV2Hq4SvqY0kJ7 Q58Y9AfNqVzPNdKbJEslLT6CbQ== X-Google-Smtp-Source: ABdhPJy9iCwh645vUP2OcGCWJwvdWLV3+aH6eXHDGo3h4iJcynP+us4jhdKvM7igbaaFM5XdEMISQQ== X-Received: by 2002:a1c:2586:: with SMTP id l128mr11940126wml.109.1634300037557; Fri, 15 Oct 2021 05:13:57 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id j16sm4827353wms.16.2021.10.15.05.13.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Oct 2021 05:13:57 -0700 (PDT) Date: Fri, 15 Oct 2021 14:13:56 +0200 From: Olivier Matz To: David Marchand Cc: Dmitry Kozlyuk , dev , Andrew Rybchenko , Matan Azrad Message-ID: References: <20211012000409.2751908-1-dkozlyuk@nvidia.com> <20211013110131.2909604-1-dkozlyuk@nvidia.com> <20211013110131.2909604-3-dkozlyuk@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag 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 Fri, Oct 15, 2021 at 01:41:40PM +0200, David Marchand wrote: > On Fri, Oct 15, 2021 at 12:42 PM Dmitry Kozlyuk wrote: > > > a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c index > > > 8d5f99f7e7..27d197fe86 100644 > > > --- a/lib/mempool/rte_mempool.c > > > +++ b/lib/mempool/rte_mempool.c > > > @@ -802,6 +802,7 @@ rte_mempool_cache_free(struct rte_mempool_cache > > > *cache) > > > | MEMPOOL_F_SC_GET \ > > > | MEMPOOL_F_POOL_CREATED \ > > > | MEMPOOL_F_NO_IOVA_CONTIG \ > > > + | MEMPOOL_F_NON_IO \ > > > > I wonder why CREATED and NON_IO should be listed here: > > they are not supposed to be passed by the user, > > which is what MEMPOOL_KNOWN_FLAGS is used for. > > The same question stands for the test code. > > Could you confirm your suggestion? > > There was no distinction in the API for valid flags so far, and indeed > I did not pay attention to MEMPOOL_F_POOL_CREATED and its internal > aspect. > (That's the problem when mixing stuff together) > > We could separate internal and exposed flags in different fields, but > it seems overkill. > It would be seen as an API change too, if application were checking > for this flag. > So let's keep this as is. > > As you suggest, we should exclude those internal flags from > KNOWN_FLAGS (probably rename it too), and we will have to export this I suggest RTE_MEMPOOL_VALID_USER_FLAGS for the name > define for the unit test since the check had been written with > contiguous valid flags in mind. > If your new flag is internal only, I agree we must skip it. > > I'll prepare a patch for mempool. > > -- > David Marchand >