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 5B4BCA0C47; Tue, 12 Oct 2021 14:53:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2475641120; Tue, 12 Oct 2021 14:53:30 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 85E24410FC for ; Tue, 12 Oct 2021 14:53:28 +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 071547F408; Tue, 12 Oct 2021 15:53:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 071547F408 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634043208; bh=AgHnpMS4Txjc06zBvnCSmqmvE5KCWWgy1swIZTmKeN4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UXk7objqcZ+Hnw/3pyJFxeIFA4eeLjil6L5faFvweWnfRLZKtittDQAQt+KVYUXXH 3ZuBbVXRLhTTRXAr4wgEZlaYDh11G48V4oxnK1zByJK9AFetAv7dF/yD5aERrA+UQu buf9iGA+eNgr6dgozVwp+x/k5QqKRF8CnmHjwRWI= To: Dmitry Kozlyuk , "dev@dpdk.org" Cc: NBU-Contact-Thomas Monjalon , Matan Azrad , Olivier Matz References: <20210929145249.2176811-1-dkozlyuk@nvidia.com> <20211012000409.2751908-1-dkozlyuk@nvidia.com> <20211012000409.2751908-3-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <29302cf0-93d7-c425-85fb-5a18d0313143@oktetlabs.ru> Date: Tue, 12 Oct 2021 15:53:27 +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 v3 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/12/21 3:40 PM, Dmitry Kozlyuk wrote: >> [...] >>> +#define MEMPOOL_F_NON_IO 0x0040 /**< Not used for device IO >> (DMA). */ >> >> Doesn't it imply MEMPOOL_F_NO_IOVA_CONTIG? > > Let's leave this explicit. NO_IOVA_CONFIG could result in MEMZONE_IOVA_CONTIG (although it doesn't now), which can affect how many pages are used, which may affect performance due to TLB caches. It sounds like a usage of a side effect of MEMPOOL_F_NO_IOVA_CONTIG absence. It does not sound good. > >> Shouldn't it reject mempool population with not RTE_BAD_IOVA iova >> parameter? >> >> I see that it is just a hint, but just trying to make full picture consistent. >> >> As the second thought: isn't iova==RTE_BAD_IOVA sufficient as a hint? > > 1. It looks true that if RTE_BAD_IOVA is used, we can infer it's a non-IO mempool. > 2. The new flag is needed or at least handly, because otherwise to check this property of a mempool, but how? Allocating a test mbuf is doable but looks like a hack. Or we can pass this information to the callback, complicating its signature. Do you think it's better? mempool knows it when the mempool is populated. So, it can just set the flag itself. > 3. Theoretically, user may want to use mempools for objects that are used for IO, but not with DPDK. In this case IOVA will be valid, but the flag can also be set. It sounds very artificial. Also in this case I guess MEMPOOL_F_NON_IO should be clear anyway. > > So I'd keep the flag and also infer it for RTE_BAD_IOVA, but allow normal IOVA. > What do you think? >