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 884D7A0C47; Tue, 12 Oct 2021 11:46:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2303F40151; Tue, 12 Oct 2021 11:46:25 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1E5D44003C for ; Tue, 12 Oct 2021 11:46:24 +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 9F7EE7F567; Tue, 12 Oct 2021 12:46:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 9F7EE7F567 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634031983; bh=hOwzcER3VuxvfIm3YcKqxBj3jjjFdk7+0Q7xR9JIxms=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gFmPv+MmowOfmxbQBaCziIbR7KuEJM7qaQHlKfcdYOzfHv4cilcecI4V9udRKBizP 4VFVkaHQrmAEMFDaYr/U2cHcKyYlKffQPl8ho8dlVBIgE2jAuj4lVErJXp+F/T63hn YMRgAT5yST9uPjDRsNpPzO4EUK3TSgW0RSfZVz0c= To: Dmitry Kozlyuk , "dev@dpdk.org" Cc: NBU-Contact-Thomas Monjalon , Matan Azrad , Olivier Matz , Ray Kinsella , Anatoly Burakov References: <20210929145249.2176811-1-dkozlyuk@nvidia.com> <20211012000409.2751908-1-dkozlyuk@nvidia.com> <20211012000409.2751908-2-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <528a616b-9045-30e2-ade1-0f4d44cb35ea@oktetlabs.ru> Date: Tue, 12 Oct 2021 12:46:23 +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 1/4] mempool: add event callbacks 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 12:37 PM, Dmitry Kozlyuk wrote: >> On 10/12/21 3:04 AM, Dmitry Kozlyuk wrote: >>> Data path performance can benefit if the PMD knows which memory it >>> will need to handle in advance, before the first mbuf is sent to the PMD. >> [...] >> >> I'd like to understand why the API is internal (not experimental). I think reasons >> should be clear from function description. > > My reasoning was that PMDs need this API while applications don't. PMDs may need to deal with any mempools and don't control their creation, while the application knows which mempools it creates and doesn't care about internal mempools PMDs might create. But maybe I was wrong and there are applications that want to use mbufs from those internal mempools for non-DPDK IO, something SPDK-like. I'll add a note about that in the description and make them experimental. > It is a good explanation. Thanks. May be it is safer to keep it internal until we find the first external user.