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 EC9E0A052E; Mon, 9 Mar 2020 14:15:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4DD3D1C069; Mon, 9 Mar 2020 14:15:32 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 428591C02E for ; Mon, 9 Mar 2020 14:15:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583759729; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ulXhOvhXIDf3qjYwkkONJ5/9EPLKji7YKwV0fvMtdls=; b=NTTbBgNxkr/ePV/9ra+NXDOz96/LeINkmVLBCoe9+pV9TUi3xG+1yx2T00tJyjgxxWDbmf 3qOI+49p8wLBV5ZF8iMa5k7lynhtgWKE34Bx32lw3myANjgnyPEa3rtZKeWSKd7z9tG93y GJnEhv+tzXkQ5cfyz1bOtMviLuoFyrI= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-172-Ueshm5wPOU2yXtaGl2nL6g-1; Mon, 09 Mar 2020 09:15:26 -0400 X-MC-Unique: Ueshm5wPOU2yXtaGl2nL6g-1 Received: by mail-ua1-f71.google.com with SMTP id t26so1430251ual.17 for ; Mon, 09 Mar 2020 06:15:26 -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=QMeDnjhLrEsEEf/psjkPnHZhhX5b/QfTC1E6bPTo+FY=; b=W4MaFBYxnEd4HIIGG8z/FW5pOX+YPSKDujdnG6av0U5ujxBC+CqmFNUjMQV+zE68Nt U3uhl+rwnTVE82+11yZgq+guSLy0OmPibyuGGHm3r6fLVGL2viqv0wmJKOeDWzK9tsVi Vx4nlJ8K6NRL0mj8J2iFrFJxbNfM7bLb7nP9Zo6K6OpVIDlW1TtINH/n9E5Lya7mE+xq JlaQWME8Te1YzflIqDGj2+CMyuH639pptCQOp6JyiWpciFb2L7c71/07bCzq0VnlR88Q sYBQMUkFdNf5rASiOnDHosPPKyN4n68PewRkVQyMn4jghCbKOi9ZSSQnUQmHUef0e+Q1 JDMQ== X-Gm-Message-State: ANhLgQ2vOf6klHs3RXr29EnIsANVVBFXju73MZ2HnEvjxWDnq64whhRa 7XLah8sVzwdIiHbPKPAOLNdPrJIy433K6a7DDiG6FOM0h5dgQZkUMJwPBxLpwZYBp0Lugxh4cK1 yv+8u1uxsGepsTxmbf6s= X-Received: by 2002:a1f:2481:: with SMTP id k123mr8652800vkk.18.1583759725472; Mon, 09 Mar 2020 06:15:25 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtHRQCoq7jpO3ymOULYHRnMzQ3QLLksgJCNv/yzV5Pga6Zm0x5K2KwdAGIkymKJxWwxtzq09SKnaX0zUkjeh+g= X-Received: by 2002:a1f:2481:: with SMTP id k123mr8652766vkk.18.1583759725051; Mon, 09 Mar 2020 06:15:25 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: David Marchand Date: Mon, 9 Mar 2020 14:15:13 +0100 Message-ID: To: Tonghao Zhang Cc: Olivier Matz , Andrew Rybchenko , Jerin Jacob , dpdk-dev , Gage Eads , "Artem V. Andreev" , Jerin Jacob , Nithin Dabilpuram , Vamsi Attunuru , Hemant Agrawal , "Burakov, Anatoly" , Bruce Richardson X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" On Mon, Mar 9, 2020 at 9:56 AM Tonghao Zhang wro= te: > On Mon, Mar 9, 2020 at 4:27 PM Olivier Matz wrot= e: > > 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 an= d > > return its index, else get the last id and copy the name in the stru= ct. > > > > 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 multipro= cess. Tonghao, could you add a unit test to exhibit the issue as part of this wor= k? Thanks. --=20 David Marchand