> > > > Subject: Re: [dpdk-dev] Sharing Common libs between PMDs > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce > > > > > Richardson > > > > > Sent: Wednesday, March 14, 2018 3:05 PM > > > > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > > > > > Cc: Liron Himi <lir...@marvell.com>; dev@dpdk.org > > > > > Subject: Re: [dpdk-dev] Sharing Common libs between PMDs > > > > > > > > > > On Wed, Mar 14, 2018 at 08:25:45PM +0530, Jerin Jacob wrote: > > > > > > -----Original Message----- > > > > > > > Date: Wed, 14 Mar 2018 09:34:40 +0000 > > > > > > > From: Liron Himi <lir...@marvell.com> > > > > > > > To: "dev@dpdk.org" <dev@dpdk.org> > > > > > > > CC: Liron Himi <lir...@marvell.com> > > > > > > > Subject: [dpdk-dev] Sharing Common libs between PMDs > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > We have several PMDs in DPDK that are using the same > > > > > > > underlying > > > > common libraries. > > > > > > > In addition, we have plans to add some new common service > > > > > > > into > > > > DPDK that already introduces too > > > > > much complexity with the way that the code is written now. > > > > > > > Therefore, we would like to move all our common functions > > > > > > > calls > > > > into one shared/common folder in > > > > > DPDK and we need to find proper place for this purpose. > > > > > > > > > > > > > > Can you suggest on such a place? > > > > > > > > > > > > There was an attempt to create "driver/common" but latter the > > > > common code > > > > > > for NXP HW device got moved to drivers/bus/dpaa/. Linux kernel > > > > > > has something called "driver/soc", I think, "driver/soc" may > > > > > > be more > > > > appropriate. > > > > > > > > > > > > Currently DPDK's driver build dependency is in the following > > > > > > order (bus, mempool, net, crypto, event). > > > > > > Other than driver/common or driver/soc, one option could be to > > > > > > - Move the common code to bus or mempool and > > > > > > - Across the drivers, include the header files through CFLAGS > > > > > > if > > > > the common code > > > > > > is in header file > > > > > > > > > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk. > > > > > org%2Fbrowse%2Fdpdk%2Ftree%2Fdrivers%2Fevent%2Focteontx%2FMakefile > > > > %23n1 > > > > > 3&data=02%7C01%7Cshreyansh.jain%40nxp.com%7Cfa7ba7a1dfd94b9336c008 > > > > d589c > > > > > 63dd7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6365664069555 > 06 > > > > 340&s > > > > > data=MkxFJUuHPuBFIqAgjmUzUcgRms9WTsxkkMQah4kGAlM%3D&reserved=0 > > > > > > > > > > > Given that this seems to be a recurring problem, I think having > > > > > a drivers/common folder may not be a bad thing. > > > > > > > > > > /Bruce > > > > We've been grappling with the same problem for QAT driver. > > > > A variant we were about to propose was to rename drivers/bus to > > > > drivers/lib. > > > > And possibly move drivers/mempool to drivers/lib As the rest of > > > > the drivers/xxx are actually PMDs, while mempool and bus are libs > > > > on which other drivers depend. > > > > I'm ok with adding a drivers/common instead, but the above seems > > > > cleaner. > > > > > > In my opinion, I think we should add a common/ without modifying the > > > bus/mempool structure. I agree > > that bus/mempool are not standalone PMDs themselves, but they are not > > libraries either in true sense - they /plug/ into the eal framework and > > *may* > provide service to drivers. > > > > > > As for common/ - that gets a +1 from me. > > > > +1 for drivers/common > Ok. > +1 for drivers/common
+1 for drivers/common
