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 8EF23A0096 for ; Wed, 10 Apr 2019 10:36:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 649B454AE; Wed, 10 Apr 2019 10:36:05 +0200 (CEST) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) by dpdk.org (Postfix) with ESMTP id EE3C44CA7 for ; Wed, 10 Apr 2019 10:36:03 +0200 (CEST) Received: by mail-ua1-f48.google.com with SMTP id d5so495707uan.6 for ; Wed, 10 Apr 2019 01:36:03 -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=bfyw3DeJIhmIKzlyxlK+LlgmjPsSYTeUzq/PQepDazM=; b=E/Ng/sWIBAqRWevLBMcazDdSqejgwePrAVi1Xtt6JB84gXfIzgkHgJ8Lh54vECCgaW kJv7INJqjzmquD36XnWtJ5esujg/STBxEsl6PttGmo0Ssc/YXkOoHzKPm/6VP95LBRue vcShk8EuY7+s3BBGzxOGct9b+pVlqdx0gn/2oWqZvRiXEoijNHq0ADrHbEFDWMGH0GQH rfdktNRVzBnbdfczeKFeZBqYz4wUl6NSivZQHVhU1PRSez1dSzttfib/Dk7jeRFTbM0i i+BabsuLKzDh21nkcNad5JwM+gNp/CQTp35whX1Ms2tfG+oeAEzasfQlzLmuZYVDavq8 QZfQ== X-Gm-Message-State: APjAAAVy0l82uQ4/wUmBE6it7FolpyisAnKqi8ucy+7YH0jtuMftx3O0 7H2ZjGPAPjb/rU6oxzN8mPxJBY/e8xB+z5alEH03Bg== X-Google-Smtp-Source: APXvYqz0iKbAZUyVsXSz7RjAtoh3UqmdBE5odwRHli+LjAbUcE7gJduzlhzHHAP+spr0kMFcUuLxonuH041xpfU/gj4= X-Received: by 2002:ab0:b05:: with SMTP id b5mr13345516uak.73.1554885363412; Wed, 10 Apr 2019 01:36:03 -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: Wed, 10 Apr 2019 10:35:51 +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: <20190410083551.cylE3mqFRqn6rZFvpCOUL0AmpF7cbYv8ndr2stnep3I@z> On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly wrote: However, there are two use cases that i can think of that are either > hard or outright not possible without our multiprocess API's. The first > one is dumping functionality. For example, dpdk_proc_info can display > info from a currently-running or defunct process - list its > memzones/mempools/etc. - basically, everything there is to know about > the shared memory can be known that way. While this isn't a "real" use > case, it is useful for debugging. > On the principle (there might be some corner cases I don't have an idea of) attaching an existing process is something that can be done with PTRACE_*. As for dumping post mortem, again, this could be done without dpdk assist. The only thing that should come from dpdk is the knowledge of where and how to dump the objects. > More importantly, our multiprocess model provides resilience. In an > event of a crash, the entire application is not brought down - instead, > only the crashed process goes down. It's not /perfect/ resilience, of > course, and there are caveats (memory leaking, locks, etc.), but you do > get /some/ resilience that way - your process went down, you spin > another secondary and you're back up and running again. > Never witnessed a recover, and yes I would suspect quite some funny situations like locks, dirty memory etc... Okay, thanks for the inputs. -- David Marchand