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 24AC0A0093; Mon, 15 Jun 2020 09:12:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A8C34C89; Mon, 15 Jun 2020 09:12:03 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id D97BD49E0 for ; Mon, 15 Jun 2020 09:12:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592205121; 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=JkC417wE0JnVMg2I17cJoNfZcna7qqPtqMcHoryISaI=; b=CmF4xHYiv8U+W/hxwY2jp7k5R9jgnqFqK0UEDyQPYUk0pBPwnTrhgkXCfr894mAoFsFSuG M/DUqoL+2exHi4azJ7mrwcpuWxdDOtQznRqz/GPjJuV/+Mdg8u2iqPbUHK3kvKpahwds2u G9DQhx7p/VeZgF9QeNddFLNgqjtJgZY= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-246-rQtVj5BkMpWtOFqjobUSkA-1; Mon, 15 Jun 2020 03:11:57 -0400 X-MC-Unique: rQtVj5BkMpWtOFqjobUSkA-1 Received: by mail-ua1-f70.google.com with SMTP id h10so6843015uao.4 for ; Mon, 15 Jun 2020 00:11:57 -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=JkC417wE0JnVMg2I17cJoNfZcna7qqPtqMcHoryISaI=; b=bIrc8UoVYHdi+sVmqbBMQVUcHGAXRfZ1jK3IUfrhUcWvVFwEqQs2gQW12JqmPiu410 EHOHEjXCeI6t0O3wqX+Ahm/VqP3pkYm4TpouG8eXQG4c9m5QkpdLh9zyCBA7MJizC5ZS LhcQsLI8yb4gs5r4cSKH1h0noMIeT9cu9Ylxz26ZlXgeonpgtYIsYEpv1ipmiI6zRt/t crpYAGDfsqfJXoI2HtS+UQEHu6l4YhqzckU6epePFz2w9ZIU1ZwIVcvJvSjZgxIXv5d0 NtXTWlUTz5Gwz0BSMBpdAWYsXTvu4NZUedy1iRnzr6CxDoKgKZ/DaONzn+E/Mig5oVO4 swqA== X-Gm-Message-State: AOAM532X2GbsCM/6BkM6V8NTQPnUaaRMewxYyJNj701HS7Hrpc7l7FbJ 8DrN1jEihs2L1Et32/yzpfy+/fj/fv0tgjXUjLFdfPz5qUrx+gAmFh2DTFzjkg/Wnor49/+rt6e UDBDFwLpqYzy0MAdVM5k= X-Received: by 2002:a67:e3a3:: with SMTP id j3mr17735490vsm.105.1592205116782; Mon, 15 Jun 2020 00:11:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1pg1FLFJ1MIPe3Z0ZQFuCGLIvLLWc0syg4O/7tHJ54OwY+1jeYbtuttZKGLaJEiiKYUDLBnKL46LKZeJ2C5M= X-Received: by 2002:a67:e3a3:: with SMTP id j3mr17735477vsm.105.1592205116426; Mon, 15 Jun 2020 00:11:56 -0700 (PDT) MIME-Version: 1.0 References: <20200610144506.30505-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 15 Jun 2020 09:11:45 +0200 Message-ID: To: Jerin Jacob Cc: dpdk-dev X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 0/7] Register external threads as lcore 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" Archived-At: List-Archive: On Wed, Jun 10, 2020 at 5:33 PM Jerin Jacob wrote: > > On Wed, Jun 10, 2020 at 8:48 PM David Marchand > wrote: > > > > On Wed, Jun 10, 2020 at 5:09 PM Jerin Jacob wrote: > > > > > > On Wed, Jun 10, 2020 at 8:15 PM David Marchand > > > wrote: > > > > > > > > OVS and some other applications have been hacking into DPDK internals to > > > > fake EAL threads and avoid performance penalty of only having non-EAL > > > > threads. > > > > > > > > This series proposes to add a new type of lcores and maps those external > > > > threads to such lcores. > > > > Those threads won't run the DPDK eal mainloop and as a consequence part of > > > > the EAL threads API cannot work. > > > > > > > > Having new lcores appearing during the process lifetime is not expected > > > > by some DPDK components. This is addressed by notifying of such lcore > > > > hotplug. > > > > > > > > This patchset has still some more work (like refusing new lcore type in > > > > incompatible EAL threads API, updating the documentation and adding unit > > > > tests) but I am sending it anyway as I would like to get this in for > > > > 20.08. > > > > > > Cool feature. > > > > > > Is mempool's lcore local cache working for external cores with this scheme? > > > > Yes, as it is stateless, all we need is a unique lcore_id in [0, > > RTE_MAX_LCORE-1] range. > > Was it the case when lcore registered and then mempool created? What > about other case, mempool created and then lcore registered? - All caches are initialised for all possible lcores for each mempool. https://git.dpdk.org/dpdk/tree/lib/librte_mempool/rte_mempool.c#n965 So any order is fine wrt the local mempool cache. - If the mempool drivers want to initialise per lcore data on demand [1], the driver have to register a lcore notifier per mempool. 1: https://git.dpdk.org/dpdk/tree/drivers/mempool/bucket/rte_mempool_bucket.c#n437 But this current series implementation does not handle registering in any order. I will fix this in v2 (and rework the locking which is quite ugly) hopefully this week. -- David Marchand