From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
dev@dpdk.org, "Horton, Remy" <remy.horton@intel.com>
Subject: Re: [dpdk-dev] [PATCH] ethdev: fix wrong memset
Date: Sat, 28 Jan 2017 21:14:03 +0800 [thread overview]
Message-ID: <20170128131403.GA20916@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <2493743.8AWo4SqSMn@xps13>
On Wed, Jan 25, 2017 at 12:16:58PM +0100, Thomas Monjalon wrote:
> > As I understand, the main problem is that rte_eth_devices[] is local,
> > while rte_eth_dev_data points to the shared memory array.
> > And rte_eth_dev_allocate() assumes that if rte_eth_devices[x] is free,
> > then rte_eth_dev_data[port_id] is also free.
> > Which is wrong in case when primary/secondary processes have different devices attached.
> > Another problem is that inside rte_ethdev.c we manipulate rte_eth_dev_data[]
> > contents without grabbing any lock.
>
> Yes there are a lot of problems with the multiproc mode because it has
> been implemented as a hack.
Oh, right, "hacky" is the word I intended to say in my last email.
> We are fixing some cases without figuring the whole picture.
Agreed.
>
> 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.
> vdev (local data) and, hopefully, primary does no hotplug of PCI dev.
>
> 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).
OTOH, an initial idea comes to my mind now is, make the port_id a global
id among primary and secondary process:
- same device will get same port id (my patch acertains that)
- different device will get different port id
--yliu
next prev parent reply other threads:[~2017-01-28 13:11 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 [this message]
2017-01-30 11:07 ` Remy Horton
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=20170128131403.GA20916@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=remy.horton@intel.com \
--cc=thomas.monjalon@6wind.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).