From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1FC6EA04AF; Mon, 4 May 2020 09:42:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 053851D42B; Mon, 4 May 2020 09:42:30 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id E4A401D40B for ; Mon, 4 May 2020 09:42:28 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id y24so7840567wma.4 for ; Mon, 04 May 2020 00:42:28 -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:user-agent; bh=iJC+CGE1/n8JSUutK1LUFxY9maemD16RmyU8ial/Quc=; b=DmAi0fJIMI3Gd3/xw/Ou+11SieG5qDXHtKUszoGmuRG/1nKP+d5vxxtDKoa+EJ+sJ4 WwNMQPu0QsgiIP7yALv1hmr4fIxlgal6PUGhkugFouS29BfW6CT3YPq9yitbd3FI2cWz 38UOLPqro8EGv1HmTH0TogBvV/rjTNZ4H78fU7+kCIkN0CgoZnaRXUmzGzKjVgG8Unur hkbumqE5/x+v+Z4oYQdC54ii/wnIiL5uknMu/JJZJPtQtwOoxBzyfpfkOC5S/8BvBLiS NnaCtiyKjwDwwXUEqlOD7xCXFY0s7keEDy2l+8kfPrMyDnoFWcx8JUPPfaiD3ffBGYUg tRWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iJC+CGE1/n8JSUutK1LUFxY9maemD16RmyU8ial/Quc=; b=b0WuKC4ST40AdyxUCXMw5VQJuAuq+5UwkryO4d5bkw+IVPnkHCeRRbgTkimlMfDT2r uFc9Va0og/+5yyMdpjndO3h3Lj2QVkfrDA2i6Iapah+nqD4NeamAHBVniG45odD63CB6 jgLsVDPFN3kCIfpPyrDkSHzHCCKKHALA7k1WG2970D+JlWhgPBgrakXK/tiZ2Ire0ZJl 0rj0R4dVdJiXMJ6ZXkFzzSqes/FEsqZeHFsihCA/YoGol96sDReUsP1LFXhnt4nCbD6x wo4XnMYVK34pOuoVFRQJ/RuShIeKYAJG4Vv1XqScgaHy02GwJ/DTXPUl/81h8qMvdMVy jVJw== X-Gm-Message-State: AGi0PuaZkXVPd2F9Q073WP0NMaemHoPWw9ziG6riVwaZeIu9PeKXEcyN 80xpJaxJlhSZCLubAk+J81nmEQ== X-Google-Smtp-Source: APiQypJi47Lwk//NLre00vsYU6g8/6FtD/tbU6FZi/TUab9g8aG0tJxBIsQhhgEKP1ULz+WsReM6xg== X-Received: by 2002:a05:600c:2218:: with SMTP id z24mr12912929wml.82.1588578148559; Mon, 04 May 2020 00:42:28 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id t2sm12180247wmt.15.2020.05.04.00.42.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 00:42:27 -0700 (PDT) Date: Mon, 4 May 2020 09:42:27 +0200 From: Olivier Matz To: Tonghao Zhang Cc: Thomas Monjalon , Andrew Rybchenko , Gage Eads , "Artem V. Andreev" , Jerin Jacob , Nithin Dabilpuram , Vamsi Attunuru , Hemant Agrawal , David Marchand , "Burakov, Anatoly" , Bruce Richardson , dpdk-dev Message-ID: <20200504074227.GA6327@platinum> References: <1583114253-15345-1-git-send-email-xiangxia.m.yue@gmail.com> <3331280.0S5aU1g85B@thomas> <9453419.OU7Dqq5WaI@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH dpdk-dev v3 2/2] mempool: use shared memzone for rte_mempool_ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hi, On Tue, Apr 28, 2020 at 09:22:37PM +0800, Tonghao Zhang wrote: > On Mon, Apr 27, 2020 at 8:51 PM Tonghao Zhang wrote: > > > > On Mon, Apr 27, 2020 at 7:40 PM Thomas Monjalon wrote: > > > > > > 27/04/2020 10:03, Tonghao Zhang: > > > > On Fri, Apr 17, 2020 at 6:27 AM Thomas Monjalon wrote: > > > > > > > > > > 13/04/2020 16:21, xiangxia.m.yue@gmail.com: > > > > > > The order of mempool initiation affects mempool index in the > > > > > > rte_mempool_ops_table. For example, when building APPs with: > > > > > > > > > > > > $ gcc -lrte_mempool_bucket -lrte_mempool_ring ... > > > > > > > > > > > > The "bucket" mempool will be registered firstly, and its index > > > > > > in table is 0 while the index of "ring" mempool is 1. DPDK > > > > > > uses the mk/rte.app.mk to build APPs, and others, for example, > > > > > > Open vSwitch, use the libdpdk.a or libdpdk.so to build it. > > > > > > The mempool lib linked in dpdk and Open vSwitch is different. > > > > > > > > > > We are supposed to use pkg-config to link DPDK. > > > > > Does the problem appear between a DPDK compiled with meson > > > > > and an application linked with pkg-config information? > > Hi Thomas, > > The library mempool linked order can trigger that problem. but when > > the library is loaded > > dynamically, trigger that problem too. > > as Olivier Matz said: > > The fact that the ops index changes during mempool driver lifetime is > > indeed frightening, especially knowning that this is a dynamic > > registration that could happen at any moment in the life of the > > application. > > > > the message in https://mails.dpdk.org/archives/dev/2020-March/159354.html > Hi Thomas, > For first patch, I guess we support a callback for other library, it > make the codes much cleaner > at eal layer. Otherwise, if we init for library, we may include their > header file. > There is a better solution ? To summarize my understanding of the issu encountered by Tonghao: Currently, it is not possible to call memzone_register() from an init function (registered with RTE_INIT()). This is needed if we want to store the list of registered mempool ops in a shared memory, available from multiprocess. Tonghao's patch 1/2 solves this issue. I tried to find alternatives to this approach, but none of them seems satisfying: - use RTE_PMD_REGISTER_VDEV() and rte_vdev_add_custom_scan() instead of RTE_INIT() in the MEMPOOL_REGISTER_OPS() macro to delay the initialization after eal_init(). This looks too complex (I made a POC of it, it someone is interested). - synchronize mempool ops in shared memory when mempool_create() is called in the primary: this would probably works most of the time, but it is not a perfect solution as we cannot ensure that the primary application will create a mempool before the secondary comes up. - introduce a mandatory call to rte_mempool_lib_init(): despite it's the usual way to initialize libs, this will break compatibility. > > > > > If the problem really needs to be solved, > > > > > the EAL patch (first of this series) needs to be discussed > > > > > and reviewed carefully. I don't imagine it being done in 20.05. > > > > OK, let's discuss it once 20.05 is out. Regards, Olivier