From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 337C8C433DF for ; Wed, 10 Jun 2020 15:33:50 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id BE6562063A for ; Wed, 10 Jun 2020 15:33:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HQ2fYbgh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE6562063A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2E814C8B; Wed, 10 Jun 2020 17:33:48 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id D7D251BED9 for ; Wed, 10 Jun 2020 17:33:47 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id c8so2671807iob.6 for ; Wed, 10 Jun 2020 08:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0KdF/94eqsKbS4xmTN3l8M5oSboZF9UDvL56A1ZsYJE=; b=HQ2fYbghudgerhzWaadVTqWNG8cDObjWnSIJ419F9LMO0XBY5rcAfRmumhWgDWTw4X xOQwa4AM143MQg7EH/6Y4A91HgBmpVpeBTEc5s5cLhzfDtaHevK0/CfG5Tyi5YZQtqYR 4lpvG0NCgCPHJR2qwNAAfLp3ttlcTzv+IZEZv+zI9+r13WvbamFWhY7voqrMH+Vt7ngH MQBrDCi7+ZLmqBmNCK0ebJCQb5q74AKb8Q36IcprVhZcBvA7sIwxPiwxj2rUcC6O3DxF wrqFxjYeIz70wm4ubpI/JCjblyP63HiwogVF708VHYDjgyDL4QnpQqquF944EkwkP5o3 7haA== 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=0KdF/94eqsKbS4xmTN3l8M5oSboZF9UDvL56A1ZsYJE=; b=motu4RRSZ7mQamRvby3nss/bYwcDw+Zj/i3wRcJW3DktB43VECJBeBpsPA17mkp/Du 3CYU1iMc2+WpthlxCn1Byx1LcZ9w25wCBBae47RObnUQmi1kLuc+dYF+FQWm1vccsvoE jphWW6FIcV4Lr7XCcpuXdLFBboh4U8CnOsHQHL0J9tccLx3CmiP7//48VlxZLeC0siZz PRAVZHzyahwUU0svGetP/DWtNwTlepztCzxsFTGNI9rAnmCQ7jni3qaCh7carI9hTAiW iZX1xvWNIw2VeCF8O6Vny2joGut8IjbwMjdAXfobURWjO1rfHaSUfZiJUmI8hF8DonKU eCRQ== X-Gm-Message-State: AOAM531y579zBkYguWgtsMGCy6WR743b977+IC4zXDKd3tfOiyYXu9Gw FsIPhFwa8VHjXGA1uZkR8ZRBuShoxV0iQzmJmRs= X-Google-Smtp-Source: ABdhPJwvvqOw/uOmFwUeQyC/RdrXsDUg/F7I3iTU9x5/7WFTMtneWeDU+j+3MQGH9C6N7Do0H2zObXrNPiewKzXkoak= X-Received: by 2002:a05:6602:2001:: with SMTP id y1mr3745972iod.94.1591803227100; Wed, 10 Jun 2020 08:33:47 -0700 (PDT) MIME-Version: 1.0 References: <20200610144506.30505-1-david.marchand@redhat.com> In-Reply-To: From: Jerin Jacob Date: Wed, 10 Jun 2020 21:03:31 +0530 Message-ID: To: David Marchand Cc: dpdk-dev 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" 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? > We could imagine flushing such caches on unregistering. > > And we can fix other mempool drivers like the bucket driver. > > -- > David Marchand >