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 B2117A0350; Wed, 24 Jun 2020 12:48:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E1FFD1D73C; Wed, 24 Jun 2020 12:48:47 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id A86E61D675 for ; Wed, 24 Jun 2020 12:48:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592995725; 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=QApDyov1v6jbXYDa+8nlrlocGGhO26h1LE3yAGaBJ/c=; b=WEt5lyBGDm/yTRLfljgShU8Wkj72NaNnkE95SuIVEx8su9Yhi7FpiwykzmgTGwH5EVbY2Q ZARHJqsFUooCTeOH23mkkWBcuGwTcRNtt/9aOlL0RFDSq9Mfpqf9t1l14/Ma8wOii9FHji 7cDFTsyj/6/B4hnBXSKhSPC06YnMmKQ= 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-278-qdjkm7FYMf2biJ6EOcZKnA-1; Wed, 24 Jun 2020 06:48:41 -0400 X-MC-Unique: qdjkm7FYMf2biJ6EOcZKnA-1 Received: by mail-vk1-f200.google.com with SMTP id g21so312885vkk.15 for ; Wed, 24 Jun 2020 03:48:41 -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=QApDyov1v6jbXYDa+8nlrlocGGhO26h1LE3yAGaBJ/c=; b=oWMdn1gZrv+RTljSe/C7adufdSF73/2SQCK0/GTytTZgjfW3cXaJnpo3Otm/vcZH6d NATD/mvUhzrxeJTW3qJjg9euaIJKuYgzKUpcz6KwpAn5eZBlJWZH7wes0yr4TnycAflT ahU/KLAed5vN2tEDaIM0oe37rcCqaGijwGLGixQOjhpIid9vocrgW1/XOJwAqcbgWeYA zqKn7k8V1ibIHWY+oI51kVAYt3Zn9zNwzRe4Dzz/wkWF+CYYzFa35GzUn1k9PA+mzaNK Q7qMogqZmw7rVgbY4dcEba5dKgJxeVg0fR0qL7ww1oUU612/Z+waqdwzs/GfBN3Bn3mj VsAA== X-Gm-Message-State: AOAM532pFyvTwsUpBJuIJFu7h5VxuM1iYBGCoqC5di66I3F08euUyaVX uaX/LaPt9ONJX0KJpZWldTKQON8HgS6gayGZjp1EIcspBlGIm57r0utm8JeQE2Ho8zEyoTL/QDu GNvh/wLyDcJkbYN1cvA0= X-Received: by 2002:a05:6122:1054:: with SMTP id z20mr22952319vkn.80.1592995720754; Wed, 24 Jun 2020 03:48:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvsLEPw6TD8x+iy43Y5EF92vpmAFD3F7xXbdnz4Yw/iyhH4+eDG+v4uvJohyTj6Am/zx3zKNxPJG8yaOLS8pA= X-Received: by 2002:a05:6122:1054:: with SMTP id z20mr22952297vkn.80.1592995720477; Wed, 24 Jun 2020 03:48:40 -0700 (PDT) MIME-Version: 1.0 References: <20200610144506.30505-1-david.marchand@redhat.com> <20200622132531.21857-1-david.marchand@redhat.com> <20200622132531.21857-7-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Wed, 24 Jun 2020 12:48:29 +0200 Message-ID: To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "jerinjacobk@gmail.com" , "Richardson, Bruce" , "mdr@ashroe.eu" , "ktraynor@redhat.com" , "Stokes, Ian" , "i.maximets@ovn.org" , Thomas Monjalon , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Neil Horman X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores 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 Wed, Jun 24, 2020 at 12:40 PM Ananyev, Konstantin wrote: > > Supporting lcore allocation in MP requires exchanges between > > primary/secondary processes like what we have for memory allocations. > > It will be quite a beast to get to work fine, while not even knowing > > if people actually want to use both. > > I don't think we need to re-implement RPC as we did for memory subsystem. > One relatively simple approach - move lcore_role[] and related lock into > shared memory (separate memzone or so). > I think it should help a lot and will solve majority of the problems. > One limitation - init/fini callbacks can be static only. > As the drawback, it will introduce change in current behaviour: > secondary process with lcore-mask that intersects with master lcore-mask > will fail to start. > Second approach - make lcore_id local process entity: > prohibit indexing by lcore_id in shared data structures. > Let say for mempool - make cache local (per process). > While that approach is probably more elegant and consistent, > it would require more work and will cause ABI (maybe API also) breakage. In all scenarii, this is quite some work. > > > For v4, I added a check to exclude MP and the new API. > > Do you mean - make this new dynamic-lcore API return an error if callied > from secondary process? > Yes, and prohibiting from attaching a secondary process if dynamic lcore API has been used in primary. I intend to squash in patch 6: https://github.com/david-marchand/dpdk/commit/e5861ee734bfe2e4dc23d9b919b0db2a32a58aee -- David Marchand