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 45E08A0A02; Thu, 25 Mar 2021 15:24:55 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E52754067B; Thu, 25 Mar 2021 15:24:54 +0100 (CET) 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 0EED740147 for ; Thu, 25 Mar 2021 15:24:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616682293; 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=WAM694lr0KIHocuqjZc96sel2oTPsOX8Yw2YpYWccWM=; b=CYB2l2hGP3H7OMiC/X6dQB/jVZXDw7OiEL9/aOn2X7IG/+oX51A65jNkYa53R7Xugs0HqR EnXeny4pDJs0Upz1G+MunRLzDfSqBGT04dkca5MV/KnwnnOyVuh++YWaU0TjpagEseh0un SOhBCmdnjNHUOFqSfJObSe2qDGbjWrs= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-258-GsYx9BVxOye_dJ9u66q2mA-1; Thu, 25 Mar 2021 10:24:51 -0400 X-MC-Unique: GsYx9BVxOye_dJ9u66q2mA-1 Received: by mail-vk1-f200.google.com with SMTP id z68so753783vkd.22 for ; Thu, 25 Mar 2021 07:24:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WAM694lr0KIHocuqjZc96sel2oTPsOX8Yw2YpYWccWM=; b=soNGzU5jdqGJg8sedEysbo32K/SxP79meWTqKTbuic6dNRYXenU5s9h3fNhrHtnX6x Q4kiQIV1hP7ruhgh46XdU7v1tXyNz7L/2IK1uNy9SMgBnO+t6+zzrzS7MO6NCjoG6M7Y gB6Bf/o9agGkZw7HMahXi0HJofoxr9T3TrYUay0MjMsZUt8ufgAOMEivNTAmT7OnT8Gx NRCRyTa2pEbT2W6U3/LPj20gS8FTqGTjVIcvVmVIHzPmt5BQV1Tc2b0YSHgunmkA4U/K UMc4GgDv91TRvmzYaA5s6Gyrr7mQ57YUyXP1142QO+q3TgkTdN873MprRH2qxHKr7Ufm vUpg== X-Gm-Message-State: AOAM530VgDbOzj1dbnrozpGT3cWHVW6MnvCltnzBbk7nuQtNsCSi2XUI gdynQz4GENNK0+ZldI7PCG1V7zU7cDCiZkiQ+Tzad9s2cvTxTjDTIdcPpt6Kas1EDJKBVNIEmeb IQIJ6zVa8dfC+nPAcARc= X-Received: by 2002:a67:d210:: with SMTP id y16mr5275676vsi.17.1616682290498; Thu, 25 Mar 2021 07:24:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxWMsR8FwDAyRPJFf+wRq2Msk4JFZ6eIO+zNhf/+NjUj6eySnlKLoY59XyYC3NyE7xX+LvSYOIIzAN8zNufgQ= X-Received: by 2002:a67:d210:: with SMTP id y16mr5275656vsi.17.1616682290308; Thu, 25 Mar 2021 07:24:50 -0700 (PDT) MIME-Version: 1.0 References: <1583114253-15345-1-git-send-email-xiangxia.m.yue@gmail.com> <3331280.0S5aU1g85B@thomas> <9453419.OU7Dqq5WaI@thomas> <20200504074227.GA6327@platinum> In-Reply-To: <20200504074227.GA6327@platinum> From: David Marchand Date: Thu, 25 Mar 2021 15:24:38 +0100 Message-ID: To: Olivier Matz , Tonghao Zhang Cc: Thomas Monjalon , Andrew Rybchenko , Gage Eads , "Artem V. Andreev" , Jerin Jacob , Nithin Dabilpuram , Vamsi Attunuru , Hemant Agrawal , "Burakov, Anatoly" , Bruce Richardson , dpdk-dev 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 dpdk-dev v3 2/2] mempool: use shared memzone for rte_mempool_ops 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 Mon, May 4, 2020 at 9:42 AM Olivier Matz wrote: > > 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. > Any news on this topic? Is this issue still a problem? -- David Marchand