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 81C91A0C4B; Fri, 15 Oct 2021 13:41:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4554D411CB; Fri, 15 Oct 2021 13:41:57 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 80BAF410F1 for ; Fri, 15 Oct 2021 13:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634298115; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=a1Xr6NUhvWn4Vvn2gWkxcShgsA10sJ6J48QQjX9E6LM=; b=QKnU9Cohne/9NgkKla0tjT0rSQbuoUcDmnyfabTNghUJn3QB5mYlh3I9XImoDfLhj3EbD/ ycJEg6beRhu7aF9GWLrKS8gU3zVLCSAohbdHq6NAemZUMBbiBIC2T3QpW1Ar/TTnw/5cju Urw7Acr66iKrIJb3RZYHOwHn5aamrKA= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-384-bWfSEIP9Mm6SIkw8bKZINw-1; Fri, 15 Oct 2021 07:41:53 -0400 X-MC-Unique: bWfSEIP9Mm6SIkw8bKZINw-1 Received: by mail-lf1-f70.google.com with SMTP id p42-20020a05651213aa00b003fd8935b8d6so6523682lfa.10 for ; Fri, 15 Oct 2021 04:41:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a1Xr6NUhvWn4Vvn2gWkxcShgsA10sJ6J48QQjX9E6LM=; b=gy1fkQY8940PhYlKlm7g1ohE5zuWRnhdD2oD9CRnlXoTgMAhwbe7r3qb2Op3mh/zgU I6EFSrV+wAO+dg5y5y1KNAL9UZIhDbNy1nwlxU/Xj/OG+mzS5wQW78XaRnUD3OH5Bolp NH92oE1IOOBgZT4Cv1yZJ+06EJyvMln4KeCqiOXa75cyDQDF9CveKtH4/i5//olzpMQZ lA7JVgkUSZsUKoWFNPI28d3/f62kmuuQPzC2L/uvAiX7HKY6PkvuRNOHLqXPvhh2Ixwz sK+LlDTmWShMz0XbJi5skuORIK+S+fjiziXeCaOztzSsiBZZw35My1QdtSnhMoeUi3od b4HA== X-Gm-Message-State: AOAM532V4+489xE91DB9n9e+vPjZpVuoJg5PWjfbWNqNx56m2OyqKQA7 1IkxSieO8CYAS0Z1FH6LQSc12o2xDMDjzUG5CSvDXydrK+riUv6Ms1EgoGVJvTiDG25lVhP5AYT b6HlFc45a1lc1Iq9vfZ0= X-Received: by 2002:a2e:a54d:: with SMTP id e13mr11666465ljn.159.1634298112287; Fri, 15 Oct 2021 04:41:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgfbgom7ASUNc1IlPIiDabutFS41M2KYU4weppVcpBqLd0wbQ/Kss0XkckkJgd77Du5iAcDEuDwTHJQTnZLJU= X-Received: by 2002:a2e:a54d:: with SMTP id e13mr11666446ljn.159.1634298112097; Fri, 15 Oct 2021 04:41:52 -0700 (PDT) MIME-Version: 1.0 References: <20211012000409.2751908-1-dkozlyuk@nvidia.com> <20211013110131.2909604-1-dkozlyuk@nvidia.com> <20211013110131.2909604-3-dkozlyuk@nvidia.com> In-Reply-To: From: David Marchand Date: Fri, 15 Oct 2021 13:41:40 +0200 Message-ID: To: Dmitry Kozlyuk Cc: dev , Andrew Rybchenko , Matan Azrad , Olivier Matz Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 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 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