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 E008AA0350; Wed, 24 Jun 2020 11:24:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 56CDC1D8C9; Wed, 24 Jun 2020 11:24:11 +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 11CCD1D739 for ; Wed, 24 Jun 2020 11:24:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592990649; 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=2F3raHFwvz64uhzxJ+S+jHGzMmpOq2bo+xR8cPkRIAw=; b=KV4l5TagHVns/lgAtGxcuXshmoKaCiKUsNYq7kgZ6xX60BjS83OMJymuWOmlbHrrAl4bVM o98k8HsnfdRSpUCtnkuN7vVu64H+zuv0uJE6Logv+qDnG+6m+E+SAJT3Rv1KRrnSFodc/i 1fehy3rJTmM8ztTDnU2VF4UBTLaGjMM= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-232-Xf12YjG-MZeAkFrwcxmgtQ-1; Wed, 24 Jun 2020 05:24:07 -0400 X-MC-Unique: Xf12YjG-MZeAkFrwcxmgtQ-1 Received: by mail-vk1-f197.google.com with SMTP id d79so270635vkf.11 for ; Wed, 24 Jun 2020 02:24:07 -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=2F3raHFwvz64uhzxJ+S+jHGzMmpOq2bo+xR8cPkRIAw=; b=gm1vGlj+9QeKwXDWInE4f6bHSxfEIo8hRhfi7siRbsvK0bR95XfxTgxQxlqL30vkep tgUn9B+BFtSoXlGkvlNYAZCkXSgak7tdvNU1wj5/Md6NHXiGVB+S3nZwZL145Kry2M8j vZYXHwYdNJczIGZ64b6P24dDZQ+E/v1UUv9eLS3JEqZK4y9wBL0614iH9sQ53MDOqU2N +xBzWquZgzNSVwNRmTms5xjJ31cyKpUyaWSukSQ4Pe9JMls9lWZED5OgCSaPnCGD0io+ g8NxIfOKOjgjKjrH77slSWhrmG0SrpB9gfR6VUsoMuF+1wSiFgL5E4qvpdpTqiP4WcwR yGYA== X-Gm-Message-State: AOAM532x35BSO5Q14Hjxz1tDVxE9oyIUkoxIrOK6do+Q10Jh1+jb7YfK UTs12T4NMpSy6Z7Klqzkmk3cANczSd1vqj39LQVS2Fj6XOGvzTGMoMPDdwA/GdSeIrfTKd1K/2n B1zhpLcRusJeqvPh7t0s= X-Received: by 2002:a67:26c2:: with SMTP id m185mr7545782vsm.39.1592990647191; Wed, 24 Jun 2020 02:24:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhJfpYC1qk/Z6CwJ/kCI4a09c5q7P1tP+I8LsqMUcff/jUnGHQ5pWcN2E1TGxfjXdk8Sr+A+dpljB/Io10ERQ= X-Received: by 2002:a67:26c2:: with SMTP id m185mr7545765vsm.39.1592990646898; Wed, 24 Jun 2020 02:24:06 -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 11:23:55 +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 Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin wrote: > > Even before this series, MP has no protection on lcore placing between > > primary and secondary processes. > > Agree, it is not a new problem, it has been there for a while. > Though making lcore assignment dynamic will make it more noticeable and harder to avoid. > With static only lcore distribution it is much easier to control things. > > > Personally, I have no use for DPDK MP and marking MP as not supporting > > this new feature is tempting for a first phase. > > If this is a strong requirement, I can look at it in a second phase. > > What do you think? > > In theory it is possible to mark this new API as not supported for MP. > At least for now. Though I think it is sort of temporal solution. > AFAIK, MP is used by customers, so sooner or later someone will hit that problem. I understand this argument. But then we don't see those customers giving feedback. > Let say, we do have pdump app/library in our mainline. > As I can see - it will be affected when users will start using this new dynamic lcore API > inside their apps. 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. For v4, I added a check to exclude MP and the new API. I am still willing to help if people do care about using both features together. -- David Marchand