From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v8 03/19] ethdev: enable hotplug on
	multi-process
Date: Wed, 04 Jul 2018 09:33:49 +0200
Message-ID: <3322666.pe3fEbMk70@xps>
References: <20180607123849.14439-1-qi.z.zhang@intel.com>
 <6685892.NTdOAgpAes@xps>
 <039ED4275CED7440929022BC67E7061153249D11@shsmsx102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Burakov,
 Anatoly" <anatoly.burakov@intel.com>, "Ananyev,
 Konstantin" <konstantin.ananyev@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 "Shelton, Benjamin H" <benjamin.h.shelton@intel.com>, "Vangati,
 Narender" <narender.vangati@intel.com>, gaetan.rivet@6wind.com
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id B70D41BEE4
 for <dev@dpdk.org>; Wed,  4 Jul 2018 09:33:55 +0200 (CEST)
In-Reply-To: <039ED4275CED7440929022BC67E7061153249D11@shsmsx102.ccr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

04/07/2018 04:26, Zhang, Qi Z:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 03/07/2018 23:57, Thomas Monjalon:
> > > 03/07/2018 17:03, Zhang, Qi Z:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 03/07/2018 14:59, Zhang, Qi Z:
> > > > > > > > +do_eth_dev_attach(const char *devargs, uint16_t *port_id);
> > > > > > >
> > > > > > > So you are duplicating rte_eth_dev_attach which is flawed in
> > > > > > > its design and should be deprecated...
> > > > > >
> > > > > > OK, just to know this, but I guess it will not be the issue, if
> > > > > > we move the dev
> > > > > sync mechanism into eal layer in future right?
> > > > >
> > > > > Future is now :)
> > > > > We must stop mixing devargs and port id in the same layer.
> > > >
> > > > Ok, is there any RFC I can learn?
> > >
> > > RFC for what?
> > > It is just a design issue that we must stop propagating.
> > 
> > Please read at this commit, which is 2 years old:
> > 	http://git.dpdk.org/dpdk/commit/?id=b0fb26685570
> > It was starting to fix early design mistakes, but unfortunately it is not yet totally
> > fixed today.
> 
> OK, rte_eth_dev_attach is going to be deprecated.
> Do you mean we will use rte_eal_hotplug_add to attach a device directly, 
> then the device driver will be responsible for propagating all the ethdev port, 
> and application could register callback for RTE_ETH_EVENT_NEW to know new ports are created, 
> is that correct?

Exact!
All what you describe is already implemented.

To make it clear, EAL and ethdev must stay 2 separate layers.
The bridge between these 2 layers is done only by PMDs.


> > > > > > > As you may have noticed, rte_eth_dev_attach() is calling
> > > > > > > rte_eal_hotplug_add() which manages the EAL device.
> > > > > > > It is wrong because the relation between an ethdev port and an
> > > > > > > EAL device is not a 1:1 mapping.
> > > > > > > We must manage the ethdev port as one of the possible
> > > > > > > abstractions of a device represented by rte_device.