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 840DE42D9A; Fri, 30 Jun 2023 23:36:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F3B72410FC; Fri, 30 Jun 2023 23:36:49 +0200 (CEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mails.dpdk.org (Postfix) with ESMTP id 423EF40EDB for ; Fri, 30 Jun 2023 23:36:49 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1b8171718a1so17225045ad.2 for ; Fri, 30 Jun 2023 14:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1688161008; x=1690753008; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Vt58WaNNGahJsVndPFVpdqgvWHnL78tSi+7gFQeTs5I=; b=OQ3V0rAdYRlj7E32NAAMsPtUEe/rfA6aAklym82iFLPBavu6ThXzcnf28JmDmi2/Pt 0BUzfm52czWh2epwVL6wyCr+5Ullq/XMhX5/w/q6dnQ+uonR9iWMFkJfBnSY/2ol3kZ6 wgVfEHXAJamBwsbJcBZ3H9HAUtJxirfvVf0j+UZvVkXqnZQ/QW/j5IBNj5/az+h/6AdN Typ/nxFchy+8zxOByim8oS8piNVGRAS10WcEYlhZyObxjQowWx82b1bA5YuiJqtutqhz 0nApjIup53i9GN9ovq1NXzvTCtjCKbIIjg1dqnZ8V6xTthTVKTszVifFG5mxpq+RJJH8 Okcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688161008; x=1690753008; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vt58WaNNGahJsVndPFVpdqgvWHnL78tSi+7gFQeTs5I=; b=Ss7CV0Fsux+li0RBi6+AuxlR2pMV7ILvAda5RyrWPhS201EcXXoNyAfBW4/SIDVoiz +IILqGXEDKmhQeBRIO4l69E59CTZ9qCYHnMnVZMhqgZM7bcMC5uZnpg44Gvz/IwEFKWk EFqErWo34xOiANCTbq5FzQ07BuZLgKl0dJ/7FOkQGwUCIBAn36Ak/tyeevwdkV14aANc 61BAnFhe7+NiKTZsbkfO/I9oSAQrx6T4F4GRzFCEbbVH6yeZ4OCQSNpP2E44DMClCmdc gjMuGRw8f8muS5DoqGGxD6F0acynWVg/QFhhZ/7OnGxQQFqV6pyM/n4JBt6w+3z2Ol3u xm2Q== X-Gm-Message-State: ABy/qLbHRGFPQ2hSKf8hlMm4e1oJG6NuvlLIFT8tMP3DxGJc6ip8R2PC LM7fJu/gu+dKAD9OCPdoAenS5Q== X-Google-Smtp-Source: APBJJlFH94UBPxi15fdWOYxPNVQh2SM8Dbw2l8xAvDAtp02IigmixadHGYhyR8ekoSP0+3/npPtCWw== X-Received: by 2002:a17:902:f687:b0:1b0:577c:2cb with SMTP id l7-20020a170902f68700b001b0577c02cbmr3655935plg.25.1688161008472; Fri, 30 Jun 2023 14:36:48 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id w6-20020a170902d3c600b001aaed524541sm1360085plb.227.2023.06.30.14.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jun 2023 14:36:48 -0700 (PDT) Date: Fri, 30 Jun 2023 14:36:46 -0700 From: Stephen Hemminger To: Olivier Matz Cc: Tianli Lai , dev@dpdk.org Subject: Re: [PATCH] mempool: fix rte primary program coredump Message-ID: <20230630143646.36cbfed6@hermes.local> In-Reply-To: References: <1636559839-6553-1-git-send-email-laitianli@tom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Thu, 27 Jan 2022 11:06:56 +0100 Olivier Matz wrote: > >=20 > > this array in primary program is different with secondary program. > > so when secondary program call rte_pktmbuf_pool_create_by_ops() with > > mempool name =E2=80=9Cring_mp_mc=E2=80=9D, but the primary program use= "bucket" type > > to alloc rte_mbuf. > >=20 > > so sort this array both primary program and secondary program when init > > memzone. > >=20 > > Signed-off-by: Tianli Lai =20 >=20 > I think it is the same problem than the one described here: > http://inbox.dpdk.org/dev/1583114253-15345-1-git-send-email-xiangxia.m.yu= e@gmail.com/#r >=20 > To summarize what is said in the thread, sorting ops look dangerous becau= se it > changes the index during the lifetime of the application. A new proposal = was > made to use a shared memory to ensure the indexes are the same in primary= and > secondaries, but it requires some changes in EAL to have init callbacks a= t a > specific place. >=20 > I have a draft patchset that may fix this issue by using the vdev infrast= ructure > instead of a specific init, but it is not heavily tested. I can send it h= ere as > a RFC if you want to try it. >=20 > One thing that is not clear to me is how do you trigger this issue? Why t= he > mempool ops are not loaded in the same order in primary and secondary? >=20 > Thanks, > Olivier Agree with Olivier, hard coded sort is not the best way to fix this. Some work is needed to address either the ordering or communicate the list = from primary/secondary