[dpdk-dev] [PATCH 10/32] net/dpaa2: introducing dpaa2 bus driver for fsl-mc bus

Hemant Agrawal hemant.agrawal at nxp.com
Wed Dec 7 13:32:31 CET 2016


> -----Original Message-----
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Sent: Wednesday, December 07, 2016 5:52 PM
> To: Thomas Monjalon <thomas.monjalon at 6wind.com>
> Cc: Shreyansh Jain <shreyansh.jain at nxp.com>; Hemant Agrawal
> <hemant.agrawal at nxp.com>; dev at dpdk.org; Richardson, Bruce
> <bruce.richardson at intel.com>
> Subject: Re: [PATCH 10/32] net/dpaa2: introducing dpaa2 bus driver for fsl-mc
> bus
> 
> On Wed, Dec 7, 2016 at 11:40 AM, Thomas Monjalon
> <thomas.monjalon at 6wind.com> wrote:
> > 2016-12-07 15:43, Shreyansh Jain:
> >> IMO, the way Bus is kept is debatable.
> >>   - should it be in EAL (lib/librte_eal/linuxapp/eal_pci.c like Bus
> >> patches) [1]?
> >>   - Should it a 'handler/driver' parallel to device drivers?
> >>
> >> I personally prefer a clean layer for buses with:
> >>
> >>   - RTE_SDK/drivers/net/dpaa2/
> >>   - RTE_SDK/drivers/bus
> >>   - RTE_SDK/drivers/bus/dpaa2/
> >>   - RTE_SDK/drivers/bus/dpaa2/dpaa2_bus.c etc.
> >
> > I agree, it is a good idea.
> 
> Indeed.

[Hemant]  I  will fix it in v2. 
> 
> >> For PCI, which is generic (or for other similar generic buses, like
> >> platform), we can keep the implementation within lib/librte_eal/linuxapp/*.
> >
> > I would be in favor of moving PCI and vdev code from EAL to drivers/bus/.
> > We can keep the API in EAL and implement the buses as drivers.
> >
> > Other opinions?
> 
> The only issue I see for now is how to pass the configuration to these drivers,
> like vdev args or the pci blacklist/whitelist.
> 
> 
> --
> David Marchand


More information about the dev mailing list