From: Remy Horton <remy.horton@intel.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] ethdev: fix wrong memset
Date: Mon, 30 Jan 2017 11:07:56 +0000 [thread overview]
Message-ID: <9681ca16-daf7-6f3f-b6e5-868fd745ab26@intel.com> (raw)
In-Reply-To: <20170128131403.GA20916@yliu-dev.sh.intel.com>
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
next prev parent reply other threads:[~2017-01-30 11:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 8:04 Yuanhan Liu
2017-01-20 10:20 ` Thomas Monjalon
2017-01-20 10:34 ` Yuanhan Liu
2017-01-20 11:09 ` Ferruh Yigit
2017-01-20 18:05 ` Thomas Monjalon
2017-01-20 11:21 ` Ferruh Yigit
2017-01-20 15:27 ` Ferruh Yigit
2017-01-22 2:45 ` Yuanhan Liu
2017-01-23 9:41 ` Ferruh Yigit
2017-01-23 10:34 ` Yuanhan Liu
2017-01-23 11:05 ` Ferruh Yigit
2017-01-23 11:24 ` Yuanhan Liu
2017-01-23 11:32 ` Ferruh Yigit
2017-01-23 11:40 ` Yuanhan Liu
2017-01-23 11:56 ` Yuanhan Liu
2017-01-23 12:44 ` Ananyev, Konstantin
2017-01-23 12:52 ` Yuanhan Liu
2017-01-23 13:06 ` Ananyev, Konstantin
2017-01-23 13:09 ` Ferruh Yigit
2017-01-25 11:16 ` Thomas Monjalon
2017-01-28 13:14 ` Yuanhan Liu
2017-01-30 11:07 ` Remy Horton [this message]
2017-01-24 8:29 ` Remy Horton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9681ca16-daf7-6f3f-b6e5-868fd745ab26@intel.com \
--to=remy.horton@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).