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 438F4A0350; Wed, 1 Jul 2020 09:49:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A57D01C138; Wed, 1 Jul 2020 09:49:06 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id BF9791C132 for ; Wed, 1 Jul 2020 09:49:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593589744; 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=UIbY3ssst1v6G2dpMSEl/85qR1IlPyuqd3Q+BoFoIus=; b=fNQes5IMEzeqpsXEOzCMCMHdYRzjpB/+rP/YUAtX46Q3m3wKq3RYEaVrRuMtkfAU5huEqi HPLs8QWvB2epcHfnORQLNJ72ttA566OGBLFskckSBOQ3BqcnCFJlw0Hwcovo40IbH5oJjU 35hxZlZsYST2O9ni7aua9o98Vkwfn/Q= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-159-uO-DHN93MX-_hcmv0kHD2Q-1; Wed, 01 Jul 2020 03:49:02 -0400 X-MC-Unique: uO-DHN93MX-_hcmv0kHD2Q-1 Received: by mail-ua1-f69.google.com with SMTP id h88so3617049uah.9 for ; Wed, 01 Jul 2020 00:49:02 -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=UIbY3ssst1v6G2dpMSEl/85qR1IlPyuqd3Q+BoFoIus=; b=t12lvpK1aJirGhfBaLjUsDNQJA1O8Xinj6g2AMI1A+qgqOeWnmEnsOyA01dG1d39vN PvblnVPBzFnE/8ThPzPxn5oLh4aNyiBZ2hmmATwjkbOc9hI4mqawhAZP5Aom9r6+aMCf rrU96w1Da8jQxXwhWFKkP4k0Y/bo6xygY2C5JD9uGBmQtvVdQd0UUPGa7jeJQKex8EMx cxETDBvwTYPopMbZsGlbfk/KC34ZwQwR6OVcn4IrUk38RIMRWIUqZQtLTaimoIUTvbTj Jmpfoq/s05zU5vDT4ZxrgDt1dsCib1+89XDAeU06/9x7Cd81jG2ZWdB4SKIRzyLHaKi6 UOHw== X-Gm-Message-State: AOAM5324Dmwb2XPr1HQYUi5/9LG3H3CmhLp+sBn3aK4P99VMC/CMYdlJ 7G5IWIdxkK/pRqsPDAnlbFPCeAxwuNjVG/M/MWt/densVV0DfEIUgcFuYUXZK1Wd+JtUeuBLKNb vXs3DC1hdFvijaU2oRhU= X-Received: by 2002:a67:2fc6:: with SMTP id v189mr17341053vsv.198.1593589742272; Wed, 01 Jul 2020 00:49:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpAZHeTYMGvuxXxfQdDExT8O+WsRyPMPG06p8rMm3+cevfewR45pp0/JGYdRbkA+TinagTCbHE3XC7GT78/Cg= X-Received: by 2002:a67:2fc6:: with SMTP id v189mr17341033vsv.198.1593589741993; Wed, 01 Jul 2020 00:49:01 -0700 (PDT) MIME-Version: 1.0 References: <20200610144506.30505-1-david.marchand@redhat.com> <2939263.AvGHZF5Fiy@thomas> <2881429.9YLJUJncU7@thomas> In-Reply-To: From: David Marchand Date: Wed, 1 Jul 2020 09:48:50 +0200 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "dev@dpdk.org" , "jerinjacobk@gmail.com" , "Richardson, Bruce" , "mdr@ashroe.eu" , "ktraynor@redhat.com" , "Stokes, Ian" , "i.maximets@ovn.org" , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Neil Horman Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com 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 Tue, Jun 30, 2020 at 8:57 PM Ananyev, Konstantin wrote: > Imagine the situation - there is a primary proc (supposed to run forever) > that does rte_thread_register/rte_thread_unregister during its lifetime. > Plus from time to time user runs some secondary process to collect stats/debug > the primary one (proc-info or so). > Now behaviour of such system will be non-deterministic: > In some runs primary proc will do rte_thread_register() first, > and then secondary proc will be never able to attach. > In other cases - secondary will win the race, and then for primary > eal_lcore_non_eal_allocate() will always fail. > Which means different behaviour between runs, varying performance, etc. If the final users finally hit the situation you describe, it means that the multiprocess had been in use so far and was known to be in use (*hopefully*). So is it not a problem of design/non-regression testing when integrating the new API in the first place? > > If we don't add any new option now, and restrict MP handling > > to error messages, it would not prevent from extending > > in future, right? > > It shouldn't I think. > Though what is the urgency to push this feature without having an > agreement first? I waited to see others' opinions (and pinged some OVS-DPDK people). I'd like an agreement too. -- David Marchand