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 77E8AA0559; Mon, 16 Mar 2020 08:55:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D0F8325D9; Mon, 16 Mar 2020 08:55:51 +0100 (CET) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id EC10FFEB for ; Mon, 16 Mar 2020 08:55:50 +0100 (CET) Received: by mail-wm1-f66.google.com with SMTP id 6so16464461wmi.5 for ; Mon, 16 Mar 2020 00:55:50 -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:content-transfer-encoding:in-reply-to :user-agent; bh=M94PE+UwUMPGaiOEnS7VLO3hikDRwmdgbd8NdbPx/Y8=; b=J7CcFTpnIiczMbCeEi4rT2FqqIJ2ZHO42YTbbiNoKcC8hXUYgQz/v/0GQ74S1JE62d AH8rJCAbGizObBoKUkv7qLS44p8l13xI8J4qHWzoGecYGW8mUpI5/IrgSPLAARTh182c +L9h4J74w/TTWPHXR0s4NHCNiScyFd5RaWX1JaoRI3mfIgNuU6oRWvfeNIWPyxADuqfB ujoF1PKAhRSz+2HGQO7lS7vTfEUm2fFm/ojy9WutZ04LMMtLdl0G5zecJT1c6Vd/hyvT u3K05i6LOba/RAk41t/OciKDLqIoSne4UpZVOVwagRSLRd2gGfPgEWCpYUpVqpd94V1z 19Rw== 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:content-transfer-encoding :in-reply-to:user-agent; bh=M94PE+UwUMPGaiOEnS7VLO3hikDRwmdgbd8NdbPx/Y8=; b=CNqFo+XrnFwf4Az/qRhODJjapIGO4nCRRLykWUfBFrlkwuXLuYS5Cit3KwkjxrGkxM HLdSHCG30EJN2EEhYHvTis3VT5P8soLse2k02is+dwzA/r+YS07reAM7ffJMGSft1/rb 3USRBoQpltdg4CwnpVRiyqzdqfZAbWysiCDPPX3l1/8QFvB9Mgi1UP5AUJQr7PXzxmL9 BMergfbPc/gKhknBmFYV3ww5Iql/fZie0j+gwbkz+0ng3Y/mX/Nx2Eww4pNpHvY6/NVH 3G67f7YIJpYpxUrlKpcU3uCcwiZanydm1pAv9tbwZitsOTXAmx8jk5efoVwBuyfwOfYQ vZ3Q== X-Gm-Message-State: ANhLgQ10U1JYGB14JHX6L05t/vuujf4jD65x9OM+J8odNKjmcQZ9ahW2 NplH58sekXgZmXzO7IPncjwntw== X-Google-Smtp-Source: ADFU+vuL6bmQn00LKrEv0vKybBLwesXCsZjqDjwyYbul+qNXad43O9XVcOcNE9slx2g3kG4RdMvJDw== X-Received: by 2002:a1c:b7c2:: with SMTP id h185mr27124097wmf.67.1584345350615; Mon, 16 Mar 2020 00:55:50 -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 m10sm2160401wmc.24.2020.03.16.00.55.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 00:55:49 -0700 (PDT) Date: Mon, 16 Mar 2020 08:55:49 +0100 From: Olivier Matz To: Tonghao Zhang Cc: David Marchand , Andrew Rybchenko , Jerin Jacob , dpdk-dev , Gage Eads , "Artem V. Andreev" , Jerin Jacob , Nithin Dabilpuram , Vamsi Attunuru , Hemant Agrawal , "Burakov, Anatoly" , Bruce Richardson Message-ID: <20200316075549.GH17125@platinum> References: <1583114253-15345-1-git-send-email-xiangxia.m.yue@gmail.com> <1583501776-9958-1-git-send-email-xiangxia.m.yue@gmail.com> <7420c590-4906-34e2-b0b8-d412df9005c8@solarflare.com> <20200309082705.GM13822@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH dpdk-dev v3] mempool: sort the rte_mempool_ops by name 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 Tonghao, On Mon, Mar 16, 2020 at 03:43:40PM +0800, Tonghao Zhang wrote: > On Mon, Mar 9, 2020 at 9:15 PM David Marchand wrote: > > > > On Mon, Mar 9, 2020 at 9:56 AM Tonghao Zhang wrote: > > > On Mon, Mar 9, 2020 at 4:27 PM Olivier Matz wrote: > > > > 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. Also, breaking the ABI is not desirable. > > > That solution is better. > > > > > > > Let me try to propose something else to solve your issue: > > > > > > > > 1/ At init, the primary process allocates a struct in shared memory > > > > (named memzone): > > > > > > > > struct rte_mempool_shared_ops { > > > > size_t num_mempool_ops; > > > > struct { > > > > char name[RTE_MEMPOOL_OPS_NAMESIZE]; > > > > } mempool_ops[RTE_MEMPOOL_MAX_OPS_IDX]; > > > > char *mempool_ops_name[RTE_MEMPOOL_MAX_OPS_IDX]; > > > > rte_spinlock_t mempool; > > > > } > > > > > > > > 2/ When we register a mempool ops, we first get a name and id from the > > > > shared struct: with the lock held, lookup for the registered name and > > > > return its index, else get the last id and copy the name in the struct. > > > > > > > > 3/ Then do as before (in the per-process global table), except that we > > > > reuse the registered id. > > > > > > > > We can remove the num_ops field from rte_mempool_ops_table. > > > > > > > > Thoughts? > > > > It seems better, just adding Anatoly and Bruce who know more about multiprocess. > > > > Tonghao, could you add a unit test to exhibit the issue as part of this work? > > > > Thanks. > Hi Olivier > any progress？will apply this patch or wait your patch? Sorry if it wasn't clear, but my proposition was just an idea, I have no time yet to work on it. Feel free to implement it by yourself, and I'll help to review the patches. Thanks, Olivier