DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH 2/4] bus/vdev: bus scan by multi-process channel
Date: Tue, 6 Mar 2018 00:50:57 +0000	[thread overview]
Message-ID: <ED26CBA2FAD1BF48A8719AEF02201E3651460F55@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <934e5f81-8356-d430-54ed-51037c92e798@intel.com>

Hi Anatoly,

> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Monday, March 5, 2018 5:37 PM
> To: Tan, Jianfeng; dev@dpdk.org
> Cc: Richardson, Bruce; Ananyev, Konstantin; thomas@monjalon.net;
> maxime.coquelin@redhat.com; Yigit, Ferruh
> Subject: Re: [PATCH 2/4] bus/vdev: bus scan by multi-process channel
> 
> On 04-Mar-18 3:30 PM, Jianfeng Tan wrote:
> > To scan the vdevs in primary, we send request to primary process
> > to obtain the names for vdevs.
> >
> > Only the name is shared from the primary. In probe(), the device
> > driver is supposed to locate (or request more) the detail
> > information from the primary.
> >
> > Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> > ---
> 
> Is there much point in having private vdevs? Granted, i'm not exactly a
> heavy user of vdev's, but to me this would seem like a way to introduce
> more confusion. How do i tell which devices are shared between
> processes, and which are private to one process? Can i control which one
> do i get? To me it would seem like it would be better to just switch all
> vdevs to being shared.

Yes, that’s the final target: to make every vdev shared between primary and secondary process.

However, now most kinds of the vdevs do not support multi-process. For those devices,

- If they are firstly probed in primary, then we will share the rte_eth_dev_data to the secondary, so that the secondary can get stats or pdump the port.
- If they are firstly probed in secondary, considering it's mostly used by the secondary process, so we will allocate the "port id" exclusively, and keep it in that secondary process privately.

Thanks,
Jianfeng

  reply	other threads:[~2018-03-06  0:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-04 15:30 [dpdk-dev] [PATCH 0/4] allow procinfo and pdump on eth vdev Jianfeng Tan
2018-03-04 15:30 ` [dpdk-dev] [PATCH 1/4] eal: bring forward multi-process channel init Jianfeng Tan
2018-03-04 15:30 ` [dpdk-dev] [PATCH 2/4] bus/vdev: bus scan by multi-process channel Jianfeng Tan
2018-03-05  9:36   ` Burakov, Anatoly
2018-03-06  0:50     ` Tan, Jianfeng [this message]
2018-03-07 14:00   ` Burakov, Anatoly
2018-03-12  3:22     ` Tan, Jianfeng
2018-03-04 15:30 ` [dpdk-dev] [PATCH 3/4] drivers/net: do not allocate rte_eth_dev_data privately Jianfeng Tan
2018-03-06  6:07   ` Matan Azrad
2018-03-06  8:55     ` Tan, Jianfeng
2018-03-07  6:00       ` Matan Azrad
2018-03-07  6:10         ` Matan Azrad
2018-03-12  3:40           ` Tan, Jianfeng
2018-03-04 15:30 ` [dpdk-dev] [PATCH 4/4] drivers/net: share vdev data to secondary process Jianfeng Tan
2018-04-19 16:50 ` [dpdk-dev] [PATCH v3 0/5] allow procinfo and pdump on eth vdev Jianfeng Tan
2018-04-19 16:50   ` [dpdk-dev] [PATCH v3 1/5] eal: bring forward multi-process channel init Jianfeng Tan
2018-04-20  8:16     ` Burakov, Anatoly
2018-04-20 14:08       ` Tan, Jianfeng
2018-04-19 16:50   ` [dpdk-dev] [PATCH v3 2/5] bus/vdev: add lock on vdev device list Jianfeng Tan
2018-04-20  8:26     ` Burakov, Anatoly
2018-04-20 14:19       ` Tan, Jianfeng
2018-04-20 15:16         ` Burakov, Anatoly
2018-04-20 15:23           ` Tan, Jianfeng
2018-04-19 16:50   ` [dpdk-dev] [PATCH v3 3/5] bus/vdev: bus scan by multi-process channel Jianfeng Tan
2018-04-20  8:41     ` Burakov, Anatoly
2018-04-20 14:28       ` Tan, Jianfeng
2018-04-20 15:19         ` Burakov, Anatoly
2018-04-20 15:32           ` Tan, Jianfeng
2018-04-20 15:39             ` Burakov, Anatoly
2018-04-19 16:50   ` [dpdk-dev] [PATCH v3 4/5] drivers/net: not use private eth dev data Jianfeng Tan
2018-04-19 16:50   ` [dpdk-dev] [PATCH v3 5/5] drivers/net: share vdev data to secondary process Jianfeng Tan
2018-04-20 16:57 ` [dpdk-dev] [PATCH v4 0/5] allow procinfo and pdump on eth vdev Jianfeng Tan
2018-04-20 16:57   ` [dpdk-dev] [PATCH v4 1/5] eal: bring forward multi-process channel init Jianfeng Tan
2018-04-20 16:57   ` [dpdk-dev] [PATCH v4 2/5] bus/vdev: add lock on vdev device list Jianfeng Tan
2018-04-23  9:47     ` Burakov, Anatoly
2018-04-20 16:57   ` [dpdk-dev] [PATCH v4 3/5] bus/vdev: bus scan by multi-process channel Jianfeng Tan
2018-04-23  9:54     ` Burakov, Anatoly
2018-04-24  5:22       ` Tan, Jianfeng
2018-04-20 16:57   ` [dpdk-dev] [PATCH v4 4/5] drivers/net: not use private eth dev data Jianfeng Tan
2018-04-20 16:57   ` [dpdk-dev] [PATCH v4 5/5] drivers/net: share vdev data to secondary process Jianfeng Tan
2018-04-24  5:51 ` [dpdk-dev] [PATCH v5 0/5] allow procinfo and pdump on eth vdev Jianfeng Tan
2018-04-24  5:51   ` [dpdk-dev] [PATCH v5 1/5] eal: bring forward multi-process channel init Jianfeng Tan
2018-04-24  5:51   ` [dpdk-dev] [PATCH v5 2/5] bus/vdev: add lock on vdev device list Jianfeng Tan
2018-04-24  5:51   ` [dpdk-dev] [PATCH v5 3/5] bus/vdev: bus scan by multi-process channel Jianfeng Tan
2018-04-24 10:09     ` Thomas Monjalon
2018-04-24  5:51   ` [dpdk-dev] [PATCH v5 4/5] drivers/net: not use private eth dev data Jianfeng Tan
2018-04-24  5:51   ` [dpdk-dev] [PATCH v5 5/5] drivers/net: share vdev data to secondary process Jianfeng Tan
2018-04-24 10:32   ` [dpdk-dev] [PATCH v5 0/5] allow procinfo and pdump on eth vdev Thomas Monjalon

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=ED26CBA2FAD1BF48A8719AEF02201E3651460F55@SHSMSX103.ccr.corp.intel.com \
    --to=jianfeng.tan@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=thomas@monjalon.net \
    /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).