From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) by dpdk.org (Postfix) with ESMTP id E6D1D2BD8 for ; Mon, 8 Apr 2019 16:39:06 +0200 (CEST) Received: by mail-vk1-f196.google.com with SMTP id h71so3076462vkf.5 for ; Mon, 08 Apr 2019 07:39:06 -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=67ZApvzPbd/0hruZc8GotR5/nlaUm6TI+Idt1tmM3KM=; b=VTCixRlscVSE8Nhe7T3SxpUqj1OtuoUhbku+usKYjX+uFC1g5+molhBhI/KC1yDvkL 2djftvU3EeRDLNasamzyw/6zwdbvDyVZjdOKeKpDya7579v16gzdik70LEQVxO/gtzkW ZoWEQeZPakeU/aUhNPmVhVsODD0D576AbjOlAH7RvaBmnwhdmD+BPo0vySje+Mg9YlLb EAzC7354Kl2u95kpMC6pTUlHIJu+2JENTfL7SLVSRqKDgUsNYDxp/r1adPymxbQaDQyD wt7hXr8iD0Hq4F+ObZxsMdv6FSrN9Pg++CQRH8U98quWH73EThNj4lHu2AV0/C3G00+F e/Jw== X-Gm-Message-State: APjAAAWyKgwwta50Esmt+qTQzRpvZCwMH7Um7N0bjidPL2KEp3Oeb5zV fvkZPtB1b0MfgNzEW2iaoOIWfMtPUdmL0rSSrGkdwQ== X-Google-Smtp-Source: APXvYqwBwutbb3I3nsA5FrGJDJdjxxoHTZ4PYn7IuaeocrEecU+kvaH92f7hPfZmLKHRrFgPRGhlnoaRdBXprY1sNJY= X-Received: by 2002:a1f:9d87:: with SMTP id g129mr16351140vke.56.1554734346293; Mon, 08 Apr 2019 07:39:06 -0700 (PDT) MIME-Version: 1.0 References: <455a61b4-891d-eaaf-d784-2be884bcacbd@intel.com> <7166381.CkH77a7QuE@xps> <5e27f573-bbf5-30f1-73ee-d35fc5191632@ashroe.eu> <6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com> In-Reply-To: From: David Marchand Date: Mon, 8 Apr 2019 16:38:55 +0200 Message-ID: To: "Burakov, Anatoly" Cc: Ray Kinsella , Thomas Monjalon , techboard@dpdk.org, Bruce Richardson , dev , Kevin Traynor Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability 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: , X-List-Received-Date: Mon, 08 Apr 2019 14:39:07 -0000 On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly wrote: > On 08-Apr-19 2:58 PM, David Marchand wrote: > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly > > > wrote: > > > > As a concrete proposal, my number one dream would be to see > > multiprocess > > gone. I also recall desire for "DPDK to be more lightweight", and i > > maintain that DPDK *cannot* be lightweight if we are to support > > multiprocess - we can have one or the other, but not both. However, > > realistically, i don't think dropping multiprocess is ever going to > > happen - not only it is too entrenched in DPDK use cases, it is > > actually > > quite useful despite its flaws. > > > > > > Well, honestly, I'd like to hear about this. > > What are the real usecases for multi process support? > > Do we have even a single opensource project that uses it? > > > > I'm aware of a few closed source usages of multiprocess. I also think > current versions of collectd rely on secondary process (there's been a > Telemetry API added to avoid that, but AFAIK the support for Telemetry > is not upstream in collectd yet), and so do/would any dump-style > applications - in fact, we ourselves include one such application in our > codebase (pdump, proc-info, etc.). > Sorry, I don't want to highjack this thread, I can start a separate thread if people feel like it. If we go with stabilisation, we must be careful that we want to support the features. So about multiprocess, again, in those closed source projects you know of, what are the usecases? For what we provide in dpdk pdump, proc-info, referring to oneself is not that convincing to me as I don't use those tools. I don't see what we could not achieve the same with a control thread running in the dpdk process and handling commands. It would be open to the outside via a more standard channel, like a UNIX socket or something like this. If we need to declare a dynamic channel, it can be constructed as an extension of the existing standard channel: we can open something like a POSIX shm and push things in it. Was this explored ? -- David Marchand From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 12330A0096 for ; Mon, 8 Apr 2019 16:39:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 461124C8F; Mon, 8 Apr 2019 16:39:09 +0200 (CEST) Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) by dpdk.org (Postfix) with ESMTP id E6D1D2BD8 for ; Mon, 8 Apr 2019 16:39:06 +0200 (CEST) Received: by mail-vk1-f196.google.com with SMTP id h71so3076462vkf.5 for ; Mon, 08 Apr 2019 07:39:06 -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=67ZApvzPbd/0hruZc8GotR5/nlaUm6TI+Idt1tmM3KM=; b=VTCixRlscVSE8Nhe7T3SxpUqj1OtuoUhbku+usKYjX+uFC1g5+molhBhI/KC1yDvkL 2djftvU3EeRDLNasamzyw/6zwdbvDyVZjdOKeKpDya7579v16gzdik70LEQVxO/gtzkW ZoWEQeZPakeU/aUhNPmVhVsODD0D576AbjOlAH7RvaBmnwhdmD+BPo0vySje+Mg9YlLb EAzC7354Kl2u95kpMC6pTUlHIJu+2JENTfL7SLVSRqKDgUsNYDxp/r1adPymxbQaDQyD wt7hXr8iD0Hq4F+ObZxsMdv6FSrN9Pg++CQRH8U98quWH73EThNj4lHu2AV0/C3G00+F e/Jw== X-Gm-Message-State: APjAAAWyKgwwta50Esmt+qTQzRpvZCwMH7Um7N0bjidPL2KEp3Oeb5zV fvkZPtB1b0MfgNzEW2iaoOIWfMtPUdmL0rSSrGkdwQ== X-Google-Smtp-Source: APXvYqwBwutbb3I3nsA5FrGJDJdjxxoHTZ4PYn7IuaeocrEecU+kvaH92f7hPfZmLKHRrFgPRGhlnoaRdBXprY1sNJY= X-Received: by 2002:a1f:9d87:: with SMTP id g129mr16351140vke.56.1554734346293; Mon, 08 Apr 2019 07:39:06 -0700 (PDT) MIME-Version: 1.0 References: <455a61b4-891d-eaaf-d784-2be884bcacbd@intel.com> <7166381.CkH77a7QuE@xps> <5e27f573-bbf5-30f1-73ee-d35fc5191632@ashroe.eu> <6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com> In-Reply-To: From: David Marchand Date: Mon, 8 Apr 2019 16:38:55 +0200 Message-ID: To: "Burakov, Anatoly" Cc: Ray Kinsella , Thomas Monjalon , techboard@dpdk.org, Bruce Richardson , dev , Kevin Traynor Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability 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" Message-ID: <20190408143855.DBuiCHf-XSg3kpz6hvC5kz4V_aFIGILneHwLUB5Pv3w@z> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly wrote: > On 08-Apr-19 2:58 PM, David Marchand wrote: > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly > > > wrote: > > > > As a concrete proposal, my number one dream would be to see > > multiprocess > > gone. I also recall desire for "DPDK to be more lightweight", and i > > maintain that DPDK *cannot* be lightweight if we are to support > > multiprocess - we can have one or the other, but not both. However, > > realistically, i don't think dropping multiprocess is ever going to > > happen - not only it is too entrenched in DPDK use cases, it is > > actually > > quite useful despite its flaws. > > > > > > Well, honestly, I'd like to hear about this. > > What are the real usecases for multi process support? > > Do we have even a single opensource project that uses it? > > > > I'm aware of a few closed source usages of multiprocess. I also think > current versions of collectd rely on secondary process (there's been a > Telemetry API added to avoid that, but AFAIK the support for Telemetry > is not upstream in collectd yet), and so do/would any dump-style > applications - in fact, we ourselves include one such application in our > codebase (pdump, proc-info, etc.). > Sorry, I don't want to highjack this thread, I can start a separate thread if people feel like it. If we go with stabilisation, we must be careful that we want to support the features. So about multiprocess, again, in those closed source projects you know of, what are the usecases? For what we provide in dpdk pdump, proc-info, referring to oneself is not that convincing to me as I don't use those tools. I don't see what we could not achieve the same with a control thread running in the dpdk process and handling commands. It would be open to the outside via a more standard channel, like a UNIX socket or something like this. If we need to declare a dynamic channel, it can be constructed as an extension of the existing standard channel: we can open something like a POSIX shm and push things in it. Was this explored ? -- David Marchand