From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bernard.iremonger@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by dpdk.org (Postfix) with ESMTP id 9E77B3784
for <dev@dpdk.org>; Thu, 3 Sep 2015 16:03:24 +0200 (CEST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
by orsmga103.jf.intel.com with ESMTP; 03 Sep 2015 07:02:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,462,1437462000"; d="scan'208";a="781942339"
Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66])
by fmsmga001.fm.intel.com with ESMTP; 03 Sep 2015 07:02:52 -0700
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.12]) by
IRSMSX152.ger.corp.intel.com ([169.254.6.220]) with mapi id 14.03.0224.002;
Thu, 3 Sep 2015 15:02:51 +0100
From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>, Neil Horman
<nhorman@tuxdriver.com>
Thread-Topic: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
Thread-Index: AQHQ4/iIrrsGaqoMN02VOjrYJZek+Z4nn9IAgABdgACAAtWp8A==
Date: Thu, 3 Sep 2015 14:02:49 +0000
Message-ID: <8CEF83825BEC744B83065625E567D7C219F4A3F4@IRSMSX108.ger.corp.intel.com>
References: <20150831125940.GC32518@hmsreliant.think-freely.org>
<2129387.iCBeS9Cg7R@xps13>
<8CEF83825BEC744B83065625E567D7C219F49ACE@IRSMSX108.ger.corp.intel.com>
<20150901191842.GA31310@hmsreliant.think-freely.org>
In-Reply-To: <20150901191842.GA31310@hmsreliant.think-freely.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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>
X-List-Received-Date: Thu, 03 Sep 2015 14:03:25 -0000
Hi Neil, Thomas,
> > <snip>
> >
> > > > You didn't remove the relationship of the ethdev to the pci driver
> > > > though, which is really the problem, An ethdev may reside on any
> > > > number of bus types (pci/usb/vmbus/virt/none).
> >
> > <snip>
> >
> > > > Whats really needed is a way to associate an ethdev with an
> > > > arbitrary bus
> >
> > <snip>
> >
> > > > > Please see email below from 6Wind
> > > > >
> > > > > http://dpdk.org/ml/archives/dev/2015-July/022107.html
> > > > >
> > > > I think you misread that. I think all Thomas is asking for
> > > > (correct me if I'm wrong Thomas), is for someone to start
> > > > refactoring the ethdev registration code so that we can have a
> > > > single init path without the need for wierd typing and differentiat=
ion at
> init time.
> >
> > <snip >
> >
> > > > We just need to
> > > > start thinking about how to make bus registration independent of
> > > > ethernet device registration, and while your patch series sort of
> > > > eliminates some of that, its really not a proper refactoring of
> > > > the sort I think Thomas is asking for.
> >
> > I am just trying to distill what the actual requirement is from the abo=
ve
> discussion.
> >
> > (1) Remove relationship of the ethdev to the pci driver.
> Correct
I plan to continue work on the RFC to address this.
>=20
> > (2) Refactor ethdev registration code so that there is a single init p=
ath.
> Correct (or mostly correct, in rereading my initial post, there may be so=
me
> ambiguitiy here)
>=20
> > (3) Make bus registration independent of ethdev registration.
> Correct
>=20
> > (4) Change all (17) PMD's to use the modified structures.
> >
> Correct (I assume the 17 number is accurate here)
There are 17 PMD directories some of which have multiple PMD's.
The total number of PMD's is 23 at present.
=20
> > The rte_eal_driver_registration() code is in librte_eal, untouched as=
yet by
> this patch set.
> >
> Correct, the code that registers an init function is a single path, which=
is great.
> However, that path requires that you specify a device type (in this case
> PMD_PDEV or PMD_VDEV to differentiate pci vs virtual devices (it uses thi=
s
> for ordering of initalization in rte_eal_dev_init, which is a hack). Wha=
t would
> be preferred would be if the structure that was registered via that macro
> only held a name and an init routine to initalize the driver itself. Insi=
de that
> init routine, the driver would then be responsible for registering with t=
he
> appropriate bus type (virtual/pci/usb/whatever). A secondary function
> would be registered as part of that process (akin to the linux/bsd probe(=
)
> method) which was called once for each instance of the device found on th=
at
> bus.
>=20
I will send a second RFC to address the eal driver registration code issues=
in librte_eal.
> > The rte_eth_driver_registration() code is in librte_ether.
> > Should the pci fields be removed from the struct rte_eth_dev{} and
> > struct eth_driver{},
> IMO, yes, they should, as the driver can store pointers to those devices =
in
> their private per-device data area. That said, there may be value in inc=
luding
> a union of all bus types in the ethdev itself, if there are higher layer =
functions
> that need to be aware of a given ethdevs bus type
I plan to park the issue of multiple bus types for now.
More consensus is needed on the best way forward.=20
=20
>=20
> > and put somewhere else or replaced with a union of bus types and
> drivers?
Regards,
Bernard.