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 9C610A0C4B; Fri, 15 Oct 2021 11:33:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82E65410F1; Fri, 15 Oct 2021 11:33:33 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 104A540692 for ; Fri, 15 Oct 2021 11:33:32 +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)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 7D7087F5F5; Fri, 15 Oct 2021 12:33:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 7D7087F5F5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634290411; bh=qBVGGXIkREXi0Z6fjDci0qJhHZvQCmRRDzkCb1cQy10=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=uU/K5WQu/19OTUXYFUFvHzeeHwF7K5Qws/gLIUYJ/N9d9mKYZ4zYxCNd5ni2Lm0UE ddFqgHIUfELc9UwCfsDSIMIeUAdioSfhmYPOhJ65X3Pyfj5BdvKn2HuqIyrLWkQXWO 2tUObJMfh/0YY03SEQoj0QbcMh/bQFNGCASrKQ0w= To: Dmitry Kozlyuk , "dev@dpdk.org" Cc: Matan Azrad , Olivier Matz References: <20211012000409.2751908-1-dkozlyuk@nvidia.com> <20211013110131.2909604-1-dkozlyuk@nvidia.com> <20211013110131.2909604-3-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <7fe50e1d-e4d8-8c92-56fd-13d5b5e413f8@oktetlabs.ru> Date: Fri, 15 Oct 2021 12:33:31 +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 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 10/15/21 12:18 PM, Dmitry Kozlyuk wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> [...] >>> diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c >>> index 51c0ba2931..2204f140b3 100644 >>> --- a/lib/mempool/rte_mempool.c >>> +++ b/lib/mempool/rte_mempool.c >>> @@ -371,6 +371,8 @@ rte_mempool_populate_iova(struct rte_mempool *mp, >>> char *vaddr, >>> >>> STAILQ_INSERT_TAIL(&mp->mem_list, memhdr, next); >>> mp->nb_mem_chunks++; >>> + if (iova == RTE_BAD_IOVA) >>> + mp->flags |= MEMPOOL_F_NON_IO; >> >> As I understand rte_mempool_populate_iova() may be called few times for >> one mempool. The flag must be set if all invocations are done with >> RTE_BAD_IOVA. So, it should be set by default and just removed when iova >> != RTE_BAD_IOVA happens. > > I don't agree at all. If any object of the pool is unsuitable for IO, > the pool cannot be considered suitable for IO. So if there's a single > invocation with RTE_BAD_IOVA, the flag must be set forever. If so, some objects may be used for IO, some cannot be used. What should happen if an application allocates an object which is suitable for IO and try to use it this way? > >> Yes, it is a corner case. May be it makes sense to cover it by unit test >> as well. > > True for either your logic or mine, I'll add it. > > Ack on the rest of the comments, thanks. >