From mboxrd@z Thu Jan  1 00:00:00 1970
From: Remy Horton <remy.horton@intel.com>
Subject: Re: [PATCH] ethdev: fix wrong memset
Date: Mon, 30 Jan 2017 11:07:56 +0000
Message-ID: <9681ca16-daf7-6f3f-b6e5-868fd745ab26@intel.com>
References: <4d897cf9-f1f4-d924-10cd-63e95b12b411@intel.com>
 <20170123125256.GH10293@yliu-dev.sh.intel.com>
 <2601191342CEEE43887BDE71AB9772583F10A841@irsmsx105.ger.corp.intel.com>
 <2493743.8AWo4SqSMn@xps13> <20170128131403.GA20916@yliu-dev.sh.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Yigit, Ferruh" <ferruh.yigit@intel.com>, dev@dpdk.org
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
 Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
 by dpdk.org (Postfix) with ESMTP id 5C6783237
 for <dev@dpdk.org>; Mon, 30 Jan 2017 12:07:59 +0100 (CET)
In-Reply-To: <20170128131403.GA20916@yliu-dev.sh.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


On 28/01/2017 13:14, Yuanhan Liu wrote:
[..]
>> I'll apply the patch from Remy which fixes a case where process creates
>
> I would ask you not to apply that. IMO, his patch may have "fixed" a crash
> he saw, but it doesn't looks like to me it really fixes anything: the driver
> may reference rte_eth_data belongs to another driver -- things can't be
> right afterwards.

I've self-NAK'd it as the code path it was aimed at no longer occurrs.


>> I'll restart this discussion with a bigger picture of what multiproc is,
>> and what are the issues.
>
> Great! And I'm keen to know how the multiproc is actually used in real
> life (and why they don't use multiple thread). Most importantly, does
> people really care about it? (I fixed few virtio multiproc issues that
> I know there are some people/companies using it, and I want to know if
> there are more).

The use-cases I'm coming across are to allow the attaching/detaching of 
external agents mainly for information-reporting purposes, without 
having to leave hooks everywhere. In this case main advantage is the 
relative ease that processes can be hot-plugged in a way threads cannot. 
I suppose something more heavyweight might be a primary process as a 
host physical interconnect, with secondary processes being virtual 
machines - in this case these might be large semi-independent code-bases 
one does not want in the same process image.

To me the major down-side with DPDK's multiprocess model is how 
address-space layout randomisation can trip things up. I know parts of 
the code seems ASLR-safe, but I very much doubt all of it is.

..Remy